Receipts

When an AI system takes an action in the real world — moves money, sends an email, updates a record — the useful question is not "did we log it?". It is "can we prove, months from now, what happened and why it was allowed?"

Most systems answer the first. Few answer the second.

A log line records the output. A trace records the code path. Neither records the rule that let the action through, the fingerprint of the policy version in force at the time, or the signature of the actor that approved it.

Without those, the record is a story. A receipt is proof.

A receipt is the atomic unit of evidence: one small, signed record covering a single independently governable unit of execution. Actor, tools called, verdicts, policy version, timestamp, and the hash of the receipt before it. Together, receipts form a chain that later verifies as a whole.

The boundary test. Could this unit be authorized, cancelled, replayed, or audited on its own? If yes, it earns a receipt. If it is just the next step inside work already authorized, it belongs inside the receipt that already covers it.

A receipt is created when execution acquires an independent authority, lifecycle, or proof obligation — a run starts, a human grants authority, an agent delegates work, or paused work resumes under a new lifecycle. Steps governed inside that same authority are recorded within the receipt, not split into new ones.

• Immutable. A sealed receipt is never rewritten. Corrections, approvals, and overrides arrive as new receipts or recorded events.
• Portable. Verifies with a small standalone tool. No account, no network, no vendor dependency.
• Sparse. Sensitive inputs are scrubbed to shapes before signing; the receipt proves the decision without exposing the payload.
• Linkable. Every receipt has a stable ID, so a decision can be shared by URL and re-opened by anyone with the right to see it.

An engineer opens a receipt link a teammate pasted in Slack. They see the exact tool call, the four rules that fired, the policy fingerprint at that moment, and a verify button that re-runs the signatures locally in the browser.

No one has to trust anyone else's screenshot. The proof is in the receipt.

Is there a receipt for every tool call or every chat message?

No. Receipts follow governable execution boundaries, not UI messages. A tool call governed inside a run that is already authorized is recorded within that run's receipt. A new receipt appears when authority changes hands — a human grants permission, an agent delegates work, or persisted work resumes under a new lifecycle.

How is a receipt different from a log line?

A log line is unsigned prose. A receipt is a small signed record whose contents can be independently verified — including that it came before the next receipt and after the previous one.

Do receipts contain the raw payload?

No. Sensitive inputs are hashed or shape-summarised before signing. The receipt proves the decision without leaking the data that drove it.

• Evidence
• Replay
• Authorities
• Receipt spec