What does the verifier check?

It checks the available receipt fields, exact committed bytes, output hash, and stated verification conditions.

Does verification prove the output is useful?

No. It checks the record's integrity and scope, not the quality or business value of an outside result.

What happens when bytes are malformed?

The verifier should report a clear failure for invalid encoding or an invalid commitment.

Why preserve exact bytes?

Hashing the exact bytes lets another verifier check the same representation without silently reserializing it.

Can a valid receipt be stale?

Yes. Reviewers must consider creation time, freshness requirements, and whether the record applies to the current request.

← zambo.dev

Public receipt verification

Check a receipt.

Every receipt has a fingerprint. If anyone changes the receipt, the fingerprint no longer matches. A match does not prove the answer is right.

Advanced: check an offline receipt

Offline AER-1 receipt check

Paste a full MCP response or its raw result._receipt object. After this page loads, the checker makes no network request. It checks the draft-10 receipt schema and recomputes SHA-256 over the exact decoded canonical bytes. Signature and chain checks remain visibly unchecked unless a real verifier is available.

AER-1 receipt JSON

The byte-change button edits only the text in this browser. It does not send or store the changed receipt. A matching hash checks the recorded bytes, not whether an outside action happened.

Open your saved receipt

This fetches the public hosted profile. Its shape is documented separately from the raw AER-1 connection receipt schema.

Read hosted profile schema · Run the read-only demo · Use the local proxy

Advanced: check a multi-step job

Verify a workflow receipt

A workflow receipt commits to an ordered list of independently verifiable step receipts. Use the worked workflow example as the reference record. Every step must independently verify through its own receipt endpoint before the workflow root is meaningful.

Exact Merkle construction

For each 1-based step, lowercase the 64-character receipt output-hash hex and remove its sha256: prefix. The leaf is SHA-256(UTF-8 bytes of decimal seq + ":" + hash hex).
At each parent level, hash the raw 32-byte left node concatenated with the raw 32-byte right node: SHA-256(left bytes || right bytes).
If a level has an odd number of nodes, duplicate its final node before pairing. Repeat until one root remains.

The example workflow is 42a3c2cf-2cdd-5b8a-aced-016e5a2fb634 and reports this root:

a4b2fcb4684cec481e4ece889ed15c7d9e47e58d9ba4fb02ea354c0cb2ca44c4

Fetch each step at /api/v2/receipt/<receipt-id>/verify. Recompute its SHA-256 commitment from the exact decoded bytes and compare the output hash with the ordered commitment shown by the workflow. Signature and chain checks are separate and remain unchecked unless independently verified.

A matching root proves the integrity and order of the listed commitments. It does not prove that the workflow succeeded in its goal, that a provider's data was true, or that an external side effect occurred.

Open the exact workflow example → · Read the receipt schema →

Verify agent receipt

Paste the receipt UUID in the form above. The public checks let you inspect the recorded result and integrity material without relying on an agent's summary.

Verify AI agent output

A valid receipt check means the saved record matches its commitment. It does not prove that the model's answer was correct or that an unobserved outside action succeeded. Review those claims separately.