Why Deterministic Receipts Matter to Auditors

The difference between a log and a receipt

Most AI systems produce logs. A log says "this happened." A receipt says "this happened, here is the proof, and here is how you can verify it."

Logs are append-only narratives. They are useful for debugging. They are not useful for compliance. An auditor cannot replay a log entry and verify that the system made the correct decision. They can only trust that the log is accurate.

Receipts are cryptographic proofs. They include the script that ran, the input hash, the gate state, the residual, and the timestamp. They are SHA-256 hashed. They are tamper-evident. An auditor can replay the exact evaluation and verify that the system made the correct decision. They don't need to trust the receipt — they can verify it.

What a PrimeSwarm receipt contains

Every governance gate decision produces a receipt with:

• Script — the ONLY Lang policy that was evaluated
• Input hash — a SHA-256 hash of the input (PII is already stripped)
• Gate state — ALLOW, DENY, or ESCALATE
• Residual — the equilibrium residual (how far from perfect balance)
• Healed indices — which fields the gate repaired
• Residual history — step-by-step convergence
• Timestamp — when the decision was made
• Identity — who (or what) initiated the request
• Receipt hash — SHA-256 of all the above

This receipt is forwarded to your SIEM in real time. It is stored in the Continuity Ledger. It is replayable in the 3D visualizer.

Why auditors care

Reconstructability

When a regulator asks "why did the system allow this transaction?" you don't need to explain. You show them the receipt. They can replay the script against the input hash and see the exact evaluation. The decision is reconstructable.

Non-repudiation

The receipt hash binds the decision to the script, the input, and the timestamp. No party can deny that the decision was made. The system cannot retroactively change the decision — the hash would not match.

Independence

The verifier that produces the receipt is open source. The auditor can run the same verifier against the same input and confirm the result. They don't need to trust your system — they can verify it independently.

Completeness

Every decision produces a receipt. Not just the interesting ones. Not just the failures. Every ALLOW, every DENY, every ESCALATE. The auditor can see the full population, not a sample.

How this differs from traditional audit trails

Traditional audit trails are logs. They say "user X did action Y at time Z." They are useful for forensics. They are not useful for proving that the system made the correct decision.

A traditional log can tell you that a trade was executed. It cannot tell you that the trade was within the risk limit, that the counterparty was not on the sanctions list, and that the dosage was within the safe range. A receipt can.

The auditor's workflow

1. Select a decision. Pick any decision from the SIEM. Any ALLOW, DENY, or ESCALATE.
2. Retrieve the receipt. The receipt hash is in the SIEM event. Pull the full receipt from the Continuity Ledger.
3. Replay the evaluation. Run the same script against the same input hash using the open-source verifier.
4. Confirm the result. The replayed result must match the receipt. If it does, the decision is verified. If it doesn't, the system has been tampered with.
5. Sign the audit. The auditor signs off, not on trust, but on verification.

Try it yourself

Run the governance gate in your browser at /try. Every run produces a receipt — you can see the script, the input, the result, and the residual. Browse all 89 test cards at /dgv/registry — each one is a receipt-generating test.

For the full verifier bundle — run all 89 cards locally and produce signed receipts — go to /try/bundle.