What is an action receipt?

An action receipt is a portable, tamper-evident record of one piece of completed work: what was proposed, which rules it ran under, who approved it, what the system did, and — critically — whether an independent check confirmed the result against the system of record.

Like a shop receipt, it covers a whole transaction and contains line items. Each step of the work is a line item on the receipt, and each line can be checked on its own.

What a receipt contains

• The work itself — what was requested, and where the request came from.
• The rules in force at the time, with their version. Not a copy of today's rules: the ones that actually applied at the moment of decision.
• The approval — who approved, when, and a fingerprint of the exact version they approved, along with what they were shown when they approved it.
• The steps, in order, each with what it did and what evidence it produced.
• The verdict — for each check: confirmed, doesn't match, or not confirmed yet.
• The provenance line — whether the record is complete, or what is missing from it.

See three real receipts →

Why "receipt" and not "log"

A log is something an operator keeps for themselves. A receipt is something you hand to someone else. The difference matters when the person asking is a customer, an accountant, an auditor, or a counterparty in a disagreement — because they need something they can check without trusting the party that produced it.

Not all receipts prove the same thing

There is a growing family of cryptographically sealed records of AI activity, and this is a good development — sealing a record so it cannot be quietly edited is real progress, and the approach has honest precedent in transparency logs and supply-chain attestation standards.

But sealing answers one question: has this record been changed since it was made? It does not answer the question underneath it: was the recorded work actually right?

A sealed record of an AI's own account of its work proves the account is unaltered. It does not prove the invoice exists, the amount matches, or the customer is the one the request came from. For that, something must go and look — independently, in the system of record, after the fact.

A receipt that records only what the system said is a tamper-evident claim. A receipt that records what an independent check found is proof of outcome. Both are useful. Only the second one settles an argument about what happened in your books.

The three verdicts, and why there are three

Most systems answer in two states: pass or fail. Real verification has a third.

• Confirmed — an independent read of your system of record matched what was approved.
• Doesn't match — the read succeeded, and the result differs. The receipt names the mismatched field(s).
• Not confirmed yet — the check could not be completed: a system was unreachable, or the data could not be read. Nothing is claimed.

Collapsing the third into either of the others is where most quiet dishonesty in software lives. "Could not determine" is an answer, and it is recorded as one.

Portability

A receipt is only useful if it survives leaving the system that made it. The format is intended to be open and independently checkable — evidence you hold, rather than a page you can only view while you remain a customer. That is a stated direction, not a shipped feature. Concretely: the format specification will publish with transparency-log anchoring, a small open-source verifier, and a public benchmark of what the format can prove versus what it cannot. See product status for when.