Your Policy Changed. Nobody Told the Receipts.

Versioning in governance systems for autonomous AI is treated as bookkeeping when it is in fact part of the decision, and the cost of that framing only becomes visible when an audit asks a question the system was not built to answer. The question is the same one every time: was this specific action correctly authorised at the moment it executed? To answer that, the system has to be able to produce the policy that was in force at that moment, not the policy that is in force now. If those two things are not distinguishable, every past decision the system claims to have made is, in audit terms, ambiguous.

It is worth being concrete about what happens when a policy is updated in place. A governance system has been running for several months, evaluating thousands of autonomous AI actions and producing receipts for each one. At some point the policy is tightened; exports, say, are now restricted to a narrower set of approved destinations. The update is applied by overwriting the existing policy document under the same identifier, with no version increment recorded anywhere in the receipts. Months later, an auditor pulls a receipt from before the tightening and asks the question. The receipt shows ALLOW for an action the current policy would deny. The receipt is intact, the hash chain is valid, the evidence is technically sound. It is also, in the only sense that matters, useless. The policy context that gave the decision its meaning has been silently replaced.

Policy Drift Rewrites The Evidence Context

Policy drift occurs when governance rules change without versioning or preserved history. In the cases worth talking about, the change is often not sabotage; it is maintenance handled badly. Policies are updated for legitimate reasons, and the problem is not the updates themselves but the fact that the update overwrites the thing past decisions depended on.

When a policy is updated in place (overwriting the previous version under the same identifier), every historical receipt that references that policy now references a document that has changed since the decision was made. The receipt’s reference is valid, but the reference’s target has moved. The governance effect is retroactive legislation: past decisions are reinterpreted under current rules. An action that was correctly authorised when evaluated may look incorrectly authorised under the current policy, or the reverse. The evidence chain cannot distinguish “authorised under the policy in effect at the time” from “would have been denied under the current policy”, because the policy in effect at the time no longer exists.

Versioning Has To Bind The Decision

Governance policies have to be versioned, and every evidence receipt has to reference the specific policy version under which the decision was made. Four properties make that work, and they belong together.

The first is explicit identity. Each policy version has a unique, immutable identifier: not just a name, but a name plus a version that never refers to two different configurations.

The second is immutable content. Once a policy version is published, its content does not change. Updates produce new versions; the previous version remains available for reference and verification.

The third is receipt binding. Every governance receipt records the policy version, not just the policy name, under which the evaluation was performed. This binding is part of the receipt’s integrity-protected content and cannot be altered without breaking the hash chain.

The fourth is replayability. Any past receipt can be verified by replaying the evaluation against the policy version recorded in the receipt. The evaluation must produce the same decision with the same inputs, because the policy version is immutable and the evaluation function is deterministic. Determinism makes any individual decision verifiable; versioning makes the chain of past decisions verifiable.

Policy identity is not bookkeeping. It is part of the decision.

The Alternative Is Ambiguity

Without versioning, historical receipts are ambiguous. The receipt says ALLOW; the current policy says DENY. Did the policy change, was the decision wrong, or was the evidence tampered with? The auditor cannot tell, because the policy has no version history. Ambiguity in governance evidence is an integrity failure, not a minor inconvenience. The entire value of tamper-evident evidence depends on the ability to reconstruct and verify past decisions, and if the policy against which the decision was made cannot be identified and retrieved, the decision cannot be verified. Unverifiable decisions cannot support governance.

Pull a receipt from your own governance system, six months old, and try to retrieve the exact policy bytes that produced it (not the current policy, the policy in effect on that day). If you cannot, your evidence chain has already dissolved; you just have not seen the audit yet.

Every policy change has to be explicit, versioned and reviewable, and historical receipts have to remain interpretable under their original policy version. Otherwise the evidence chain dissolves the moment someone changes a rule, and the audit question becomes impossible to answer — not because the action was wrong, but because the organisation destroyed the rule that would have proven it either way.