A Hash Is Not Freshness: Why Evidence Reuse Needs a Dependency Manifest
A seal can prove that a record has not changed. It cannot prove that the record is still applicable. That requires a declared dependency manifest and an explicit material change test.
Cryptographic integrity is necessary but it is not enough. A sealed package can faithfully preserve an old policy, stale evidence, expired delegation or obsolete calculation. The hash will still match. That proves preservation, not present applicability.
Recent research replaying 38,083 commits from 714 public data version control pipelines found that incomplete dependency declarations can lead systems to reuse results after material code, configuration or environment changes. The authors do not claim this is a representative industrial rate. Their central result is narrower and more useful: safe reuse depends on knowing what the result depended on.
The dependency manifest in Replay
Anunnaki.Live now seals a manifest alongside the evidence package. It names the relied on evidence items and digests, governing basis, criteria bundle, computation method and material change triggers. For a determination or audit, the relevant authority, scope, time boundary, population and external receipt are also dependencies when they are part of the conclusion.
When a later reliance event occurs, the system must compare the current state to that manifest. A material difference does not damage the historic record. It changes its status for new reliance and opens the next necessary work.
Freshness must be stated plainly
The package no longer implies freshness merely because a file was preserved. It displays the historical capture time and whether currentness has been reassessed. Until a connected enterprise source or review supplies that comparison, the status remains historical record only.
Source: Reusing Assurance Evidence in AI Pipelines. Read the complete Replay upgrade here.