What is an action receipt?

This is what you pull up inside Lighthouse when you need to know exactly what happened on one case — not a separate feature, the same record your operations manager already sees from the queue.

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 an action receipt proves — and what it does not

An action receipt proves three things, and only when all three are true together:

• A named person committed to this exact version. Approval is granted before the action, tied to the version actually used — not a general sign-off.
• What was approved cannot be silently altered. Sealed the moment it's committed, so a later edit shows up as a change, not a rewrite of history.
• Your own systems, read by a separate account, at any later time. Confirmed by an independent read-back — not by the system's own claim that it worked.

Remove any one and what's left is a claim, not a receipt.

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.

What each rung cannot do

Every mechanism has a scope. The three rungs we just described have theirs — and naming them here, in the same section that describes the rungs themselves, is the honest form of the architecture. A vendor whose limits section is generic hasn't examined their own system; a vendor whose limits map onto their own structure has.

Rung 1 — Human Approval — cannot make a bad decision good. A person seeing accurate facts can still approve a decision that shouldn't be made. A price that comes genuinely from your customer's message can still be the wrong price for the deal. Grounding — knowing the values are real — is not the same as correctness. The architecture ensures the person approving sees the facts as they are; what they do with those facts is judgment we cannot replace and should not try to.

Rung 2 — Cryptographic Seal — cannot prove the sealed content was true, and depends on how the signing key is held. A hash preserves the content it wraps against later alteration — it does not verify the content was correct when sealed. That is why the other two rungs exist. There is also a custody dimension: if the signing key that produces our seals were ever compromised, an attacker could forge signatures on fabricated receipts. Our answer to that has four parts, and every part is committed roadmap, not a shipped feature — we'd rather say that plainly than let a "today" slip in before it's true:

• A public verifier at a well-known address. Anyone will be able to drop a receipt file in and confirm two things — it hasn't been altered since sealing, and it was signed by a specific Pruvato key — entirely in their own browser, nothing uploaded to us.
• A published, append-only key manifest. The public half of every signing key we've ever used, with the date each became active and the date each was retired, at a fixed URL that only ever grows. The private half never leaves the signing environment and is destroyed on retirement.
• Transparency-log anchoring. Publishing each receipt's hash to a public append-only log at seal time — a stronger guarantee than a signature alone, because it proves we didn't sign a receipt after the fact.
• Verification against your own books. A mode of the verifier that reads the described record from your accounting system and confirms it still matches — real engineering, built once a design partner has asked for it.

All four ship on the same trigger: the first open-format receipt shipping to a design partner — this page will say "today" the day that's true, not before. And even once all four exist, the honest statement will still be that key custody is a trust we ask you to place in us, not something the cryptography alone eliminates. The public key history and the transparency log are what will make that trust checkable rather than blind.

Rung 3 — Independent Read-back — detects; it does not prevent. The read-back catches when your books no longer match what you approved — a manual edit in your accounting system, a change made by another tool sharing the same credentials, a customer-facing action taken by someone with their own access. What the read-back cannot do is stop those things from happening. No vendor can, or should, be able to prevent you from editing your own records. And no execution architecture reaches actions taken through tools other than this one, even when they use the same credentials — that governance has to happen where those tools live, not here.

And one honest limit above the three

Even together, the three rungs describe what happened — not what should have happened. A receipt confirmed against your books proves the world matches the approved version. It does not prove the approved version was the version your business needed. That last question is the one the Health Check exists to help you answer, before you commit to a workflow that will run this many times.

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.