The Audit Will Ask for the Receipt

An auditor never asks whether the governance system was running. They ask about a specific action, weeks or months after it executed, and the system either produces verifiable proof of the decision or asks to be trusted. I have watched several teams pass the first moment confidently and fail the second. The gap between the two is the gap between governance and the appearance of governance.

When the auditor arrives, whether for an incident, a routine review or a regulatory examination, the questions are remarkably consistent across all three. They do not ask whether the AI was well-intentioned, whether the model was state of the art, or whether the framework was popular. They ask one question with several supporting parts: was this specific action authorised before it executed? Under what policy? Through which delegation chain? Can you prove it?

The answer is a receipt, or it is nothing. By receipt I do not mean a dashboard screenshot, a log excerpt or a sentence in an incident report. I mean a tamper-evident evidence record that carries the decision into a future review, where the system that made the decision may be unavailable, distrusted or already replaced.

The Auditor Needs Reconstructable Evidence

The auditor needs five specific, verifiable artefacts. Not summaries, not dashboards, not narrative explanations. The first is the canonical action: the structured representation of what was evaluated, including actor, intent, target, parameters and an evaluation timestamp. A log entry is not enough, because a log records what a system says happened. The auditor needs the representation the governance system actually evaluated.

The second is policy identity. The receipt has to identify which policy, at which immutable version, governed the evaluation. Not the current policy, and not a policy with the same name, but the policy that was in effect at the time of the decision and can still be retrieved.

The third is the delegation chain. The record has to show the authority under which the action was claimed: who delegated to whom, with what scope, until when, and whether the delegation was valid and unrevoked at the time of evaluation. Identity alone does not answer this. The question is not only who acted, but whose authority the action used.

The fourth is the decision itself: exactly one of ALLOW, DENY, or ESCALATE. Not a score, not a probability, not “allowed with conditions.” The decision has to follow from the canonical action, the policy and the delegation, or it cannot be reconstructed later.

The fifth is the integrity proof. The receipt has to carry cryptographic evidence that it has not been altered since it was produced: a hash chain linking this record to the one before it, a signature that proves which system authored it, and collision resistance so that two different inputs cannot silently stand behind the same record.

Together those five artefacts make the receipt. Separately they are fragments: the canonical action without the policy is an event without context, the policy without the delegation is a rule without authority, and the decision without the integrity proof is a claim without evidence.

The Auditor Replays the Decision

The auditor takes the receipt, extracts the canonical action, the policy version and the delegation artefacts, feeds those inputs through the evaluation function on a different machine, and compares the output to the recorded decision. If the outputs match (same inputs, same deterministic function, same decision), the receipt is verified and the governance claim is substantiated. If the outputs do not match, something is wrong: the receipt may have been tampered with, the policy version may have been recorded incorrectly, or the evaluation function may have a defect. The mismatch is itself evidence that governance integrity has been compromised.

The verification step matters most because it does not require access to the originating system. The auditor does not need the governance system’s logs, configuration or runtime state. The receipt is self-contained, and the check is independent of the system that produced it. That, in practice, is what “independently verifiable” means.

The Receipt Carries the Decision Forward

Every property that makes governance of autonomous AI action serious narrows to the same artefact. The action boundary as the right layer for evaluation, the independence of governance from the framework, the distinction between content safety and action authority, the requirement that authority be explicitly delegated rather than inferred from credentials, the necessity that evaluation be deterministic, the cryptographic integrity of the evidence, the fail-closed default when evaluation cannot complete, the revocation property that distinguishes delegation from standing permission, the versioning that keeps historical receipts interpretable, the behavioural evidence plane that catches what per-action enforcement cannot, and the adapter as the boundary where framework-specific representation becomes canonical fact. All of these exist so that the receipt can carry the decision into a future moment where it has to stand on its own.

The receipt is proof, not a log entry, not a dashboard metric, not a compliance checkbox: cryptographic, tamper-evident, independently verifiable proof that a governance decision was made before an autonomous action executed, under an identified policy, within a verified delegation, with an explicit outcome.

When the auditor asks about a specific action, the system either produces that proof or asks to be trusted. The receipt is the evidence that keeps the decision available after the runtime moment has passed.