Archive policy
Evidence that changes has to say so.
We hold the key that signs every audit, so we could issue a second, contradictory pack and it would verify. Without a published rule, that possibility is an unprovable suspicion. With one, it is a violation of something we wrote down first. This page is that rule.
The rule
01
A pack is never edited
Once an evidence pack is signed, its bytes are final. There is no revision, no patch, no quiet correction. Any change at all produces a different manifest hash, which is why editing is not merely against policy but arithmetically visible.
02
A replacement names what it replaces
When an audit has to be re-issued, the new pack carries a supersedes field holding the manifest hash of the pack it replaces and a written reason. The field sits inside the signed manifest, so it cannot be added or stripped after signing without breaking the signature.
03
The reason is written, not implied
Legitimate reasons are things like a corrected scope statement, a finding we got wrong, or a re-run after remediation. "Client requested" is not a reason on its own. Whatever is written there is signed along with everything else and can be quoted back at us.
04
A case ID is never reused without a link
Two packs may share a case ID only if the later one supersedes the earlier one by hash. An unlinked second pack under the same case ID is a policy violation, and this page is what makes that sentence meaningful.
Two different things, often confused
Our privacy notice says you can delete your audit outputs at any time. That is still true and this policy does not take it back. Deleting your own record is your right over your own data.
What this policy forbids is different: us issuing a second version of an audit that contradicts the first without saying so. One is you removing your copy. The other is us rewriting history. Only the second is banned here.
One consequence follows honestly from that. If you delete your record and we have published nothing, the only surviving copy of the pack is the one you were given. Keep it. A signed pack verifies forever without us, which is the point of the format.
Where the rule comes from
This is not our invention. Audit documentation standards have worked this way for a long time: working papers are retained rather than replaced, and any change after the report date is recorded with what changed, who changed it, when, and why. PCAOB AS 1215 and ISA 230 both take that shape. We borrowed the shape because the failure mode it guards against is exactly ours.
How you check it
Open any pack and look for supersedes in the manifest. If it is there, it gives you the manifest hash of the pack it replaced and the reason. Take that hash to whoever holds the earlier pack and the two line up or they do not. The verify page recomputes the signature over the whole manifest, so a supersedes field that was added or removed later fails the check.
What this rule cannot do
A published rule is not a mechanism. Nothing here physically stops us from signing a second pack that never mentions the first. If you hold both, the missing link is obvious and you can hold us to this page. If you hold only one, you cannot tell.
Closing that gap takes something outside our control: a timestamp from a third party, or a public append-only log every pack is written to. We are building toward the second and the first already appears in packs as a time anchor. Until it is finished we would rather describe the hole than let this page read stronger than it is.
Think we broke it
If you are holding two packs that should be linked and are not, write to hello@zerorecall.ai. A rule nobody can report a breach of is decoration.