The version-aware fingerprint is the part I would stress with a dependency-only deployment. If proration-engine changes while invoice-orchestrator stays on the same artifact, a finding keyed to the entry service can remain apparently current even though the three-hop explanation is no longer valid.
I would bind a reusable finding to the versions of the traversed services, requirement and relationship evidence that actually supported it. Then change one downstream artifact or route edge without changing the ticket inputs and require a fresh verification. That tests whether invalidation follows the dependency chain rather than only the selected service's rollback control.