Skip to content
Install
MenuClose
curl -fsSL https://excellent.so/install.sh | sh

Sign inmacOS today

Receipts

A receipt is what a verification leaves behind, signed and kept on your machine

Each accepted result leaves a receipt you can open later, cite during review, or use to compare agent setups. This one is real, from the docs: its verdict is FAIL. Point at any line to see what it binds.

Check one yourselfReceipt format

Open a real receipt

sample-receipt.jsonReal, from the docs
  1. {
  2. "schemaVersion": 1,
  3. "serviceVersion": "2026-08-16.v1",
  4. "receipt": {
  5. "schemaVersion": 1,
  6. "id": "receipt_v0_release_4df3dd89b3e4d0a0",
  7. "tenantId": "tenant_v0_release",
  8. "runId": "run_v0_release_e44941560b9f",
  9. "parentReceiptId": null,
  10. "status": "FAIL",
  11. "checkResultIds": ["G00:PASS", "G01:FAILING", … 13 more],
  12. "evidenceHashes": ["sha256:437284d4…", … 4 more],
  13. "policyVersionRefs": ["policy_v0_release@2026.08"],
  14. "engineVersion": "v0-release@1",
  15. "issuedAt": "2026-09-16T12:37:22.257Z",
  16. "signature": { "algorithm": "ed25519", … 2 more }
  17. },
  18. "binding": {
  19. "predicate": "excellent.verification.agent-work-receipt.v1",
  20. "workItemId": "work_cand_9b618ed027764ef4bccf2a64_df-001",
  21. "workSnapshotId": "wsnap_work_cand_9b618ed027764ef4bccf2a64_df-001",
  22. "attemptId": "promo_23247c38c4574c96893c2036:release",
  23. "contractId": "verification-api/2026-08-16.v1",
  24. "evidenceSnapshotId": "evsnap_v0_release_4df3dd89b3e4d0a0",
  25. … 2 more fields
  26. "evaluatorRefs": ["evaluator:evidence-integrity", … 2 more],
  27. … 8 more fields
  28. "subject": { "treeHash": "git-tree:fcd3f669…", … 6 more },
  29. … 22 more fields
  30. },
  31. "payloadHash": "sha256:ea48ebc0c…",
  32. "signature": { "algorithm": "ed25519", "value": "ed25519:COSk…", … 1 more },
  33. "publicVerification": { "receiptId": "receipt_v0_rel…", … 8 more }
  34. }
Folded where a value runs long or the docs do not explain a field. Every field is in the viewer below.
Receipt…4df3dd89b3e4d0a0
Issued2026-09-16
SignedEd25519
VerdictFail
Looking atreceipt.status
On the receiptline 10

What it binds

One of the six verification states (PASS, MISMATCH, FAIL, UNKNOWN, NOT_RUN, PENDING). Here: FAIL.

Value

"FAIL"

What it binds is the docs’ own text, from “What each part is for”. A field the docs do not explain says so.

Point at a line, tap it, or tab to the receipt and use ↑ ↓.

Real receipt

Real receipt from the Excellent docs. Synthetic release evidence, genuine signature. Verdict: FAIL. A valid signature proves the receipt was not altered. It does not make the verdict good. Source

Open every field in the receipt viewerReal receipt · all fields
release-receipt.jsonReal, from the docs
  1. {
  2. "schemaVersion": 1,
  3. "serviceVersion": "2026-08-16.v1",
  4. "receipt": {
  5. "schemaVersion": 1,
  6. "id": "receipt_v0_release_4df3dd89b3e4d0a0",
  7. "tenantId": "tenant_v0_release",
  8. "runId": "run_v0_release_e44941560b9f",
  9. "parentReceiptId": null,
  10. "status": "FAIL",
  11. "checkResultIds": [
  12. "G00:PASS",
  13. "G01:FAILING",
  14. "G02:FAILING",
  15. "G03:PASS",
  16. "G04:PASS",
  17. "G05:PASS",
  18. "G06:PASS",
  19. "G07:PASS",
  20. "G08:PASS",
  21. "G09:RUNNING",
  22. "G10:PASS",
  23. "G11:PASS",
  24. "G12:BLOCKED_EXTERNAL",
  25. "G13:FAILING",
  26. "G14:PASS"
  27. ],
  28. "evidenceHashes": [ … ],5 items
  29. "policyVersionRefs": [ … ],1 item
  30. "engineVersion": "v0-release@1",
  31. "issuedAt": "2026-09-16T12:37:22.257Z",
  32. "signature": { … }3 fields
  33. },
  34. "binding": { … },40 fields
  35. "payloadHash": "sha256:ea48ebc0c36dced1cefd90ae750220594dd2e3124cc67c6ecb9ac524a2b55ca9",
  36. "signature": { … },3 fields
  37. "publicVerification": { … }9 fields
  38. }
Folded lines open with a click or EnterEvery field as published
Receipt…4df3dd89b3e4d0a0
Issued2026-09-16
SignedEd25519
VerdictFail

Fifteen checks: ten pass, three failing, one running, one blocked outside the run. One unresolved check sinks the set, so the receipt says FAIL.

Looking atreceipt.status
On the receiptline 10

What it binds

One of the six verification states (PASS, MISMATCH, FAIL, UNKNOWN, NOT_RUN, PENDING). Here: FAIL.

Value

"FAIL"

See also

What it binds is the docs’ own text, from “What each part is for”. A field the docs do not explain says so.

Point at a line, tap it, or tab to the receipt and use ↑ ↓. Enter opens a folded line.

A receipt binds the work, the evidence, the policy and the verdict into one document, hashes that document and signs the hash. Its purpose is that you do not have to trust the machine that produced it, or us.

Evidence, binding, signature

The evidence and the binding go into one document, and the signature covers its hash

Evidence is collected against the exact attempt that produced it: command output and exit codes, logs, screenshots, diffs, CI runs and reviewer notes. Anything larger than 1 MiB is written to content-addressed files beside the database.

The binding names the exact work item, attempt, contract and evidence snapshot, which evaluators decided, and the artifact itself: a git tree hash, a commit, a build, an environment. Without the binding, a PASS is a verdict about nothing in particular.

The payload hash is a sha256 of a canonical rendering of a fixed list of fields: keys sorted, no whitespace. Reformat the file and it still verifies. Change one character of the content and it does not.

The signature is Ed25519 over that hash. Receipts are append-only: a re-verification is a new receipt that points at the one it supersedes, so nothing edits history.

Command output and exit codes

Screenshots, traces and browser observations

Diff summaries tied to the exact attempt

Evidence notes reviewers can inspect later

Proof attached to the work.

Check one yourself

Check one in under a minute, on a machine that has never had Excellent on it

The format is published as a JSON Schema, with a verifier you can read in one sitting. Node 18 or newer, no dependencies. Exit 0 when the pack verifies, 8 when it does not, 2 on a usage error.

~/receipt-check · zsh
~/receipt-checkcurl -fsSLO https://www.excellent.so/verify-receipt.mjs
~/receipt-checkcurl -fsSLO https://www.excellent.so/receipt-example.json
~/receipt-checkcurl -fsSLO https://www.excellent.so/receipt-example-key.pub.pem
 
~/receipt-checknode verify-receipt.mjs receipt-example.json --pubkey receipt-example-key.pub.pem
Excellent receipt check — receipt-example.json
 
PASS pack shape
schemaVersion 1, envelope and trust root present
PASS signature algorithm is Ed25519
signature.algorithm = ed25519
PASS canonical binding present
the receipt is bound to a work snapshot, contract, evidence snapshot, evaluator, determination, enforcement decision, review and build
PASS payload matches its hash
recomputed sha256:ee27611cb8b1d02d3edca0ad12308a64409930de759f7fc64c9f39042387b5bc from the receipt content and it matches envelope.payloadHash
PASS envelope summary agrees with the receipt
publicVerification restates the receipt id, run, tenant, key and hash without contradicting them
PASS receipt and envelope carry the same signature
receipt.signature mirrors envelope.signature
PASS Ed25519 signature verifies
the signature over sha256:ee27611cb8b1d02d3edca0ad12308a64409930de759f7fc64c9f39042387b5bc checks out against the public key you supplied
PASS signing key is declared by the pack
trustRoot declares key_example_2026_09
PASS key fingerprint matches the one you pinned
sha256 over your PEM file is sha256:7e7b79a7135e246e76931580fd56a5d49fe94b2024c18dc81157038822bd1b4c, which is the fingerprint the pack declares for key_example_2026_09
PASS ledger anchor
the ledger and audit log match anchor sha256:ba2658d08481e61503a281a16ab83a37edcd54521475e33d5571fc6809258c0f, recorded to operator-held-file at 2026-09-23T17:05:00.000Z
 
RESULT: VERIFIED
~/receipt-check
Real output, from the receipt format docs

The example pack is synthetic: the work it describes is invented; the envelope, hash, signature and anchor are the real pipeline.

Then break it

Change any character of the receipt’s content and run the same command again

Reformatting does not break it: the signature covers a canonical rendering, not the bytes on disk.

Shown: the receipt’s status edited from PASS to FAIL.

~/receipt-check · zsh
~/receipt-checknode verify-receipt.mjs receipt-example.json --pubkey receipt-example-key.pub.pem
FAIL payload matches its hash
envelope.payloadHash is sha256:ee27611cb8b1d02d3edca0ad12308a64409930de759f7fc64c9f39042387b5bc but the content canonicalizes to sha256:7930319d69b2c1fceb5c0a4bc0187b57789c55df8a2dbc523685827afa6a08e2 — the receipt body has been altered since it was hashed
RESULT: NOT VERIFIED
~/receipt-check
Real output, from the receipt format docs: the failing check and the result

Signature

A valid signature proves the receipt was not altered, and it does not prove whose key signed it

Pin the key’s fingerprint through a channel this system does not control.

It does establish

The receipt has not been altered since the holder of that key signed it. That is tamper-evidence, and it is real.

It does not establish

That the key is your tenant's key. A receipt re-signed under an attacker's key verifies cleanly against that attacker's key. Confirm the key's fingerprint through a channel this system does not control, then pin it.

A receipt also does not prove every external source was truthful; it proves which records were bound and signed together.

excellent-mcp verification universal-trust-root --json

fetches a tenant's published trust material.

The CLI on npm today, 0.1.0 (checked October 23, 2026), predates excellent-mcp verification, so this command answers unknown command until the next release. The verifier above needs only Node.

Evidence you can point at

A compact computer printed as a fine black dither on white, with 59 check boxes over it: 58 filled amber and one empty box circled by hand.
Compact computer, T7 printOne box per check, in reading order. The log line gives only counts, so each box carries a number and no check name.

Real check run · L-063

58 of 59 checks passed, so the gate says fail

Each amber box stands for a check that passed in a real run from our own logs. The ringed box is the one that failed. Point at a box to see which.

Log lineL-063
Run date2026-10-03

test-checker-gate-decision: FAIL — 58/59 checks, 35/36 mutants caught

Checks59
Passed58
Failed1
Looking atCheck 59 of 59 · failed
On the printx 67.6% · y 84.5%
Provesthe log line above

58 of 59 checks, in a run from our own logs on 3 October 2026.

Limits

What receipts do not do yet

From the security page, “Receipts, and what they prove”.

  • They stay on the machine that made them.

    Verification evidence does not sync between teammates.

  • No published signing-key distribution.

    You obtain the key out of band.

  • No outside anchor by default.

    So a receipt carries no independent proof of when it existed.

Install

Make your first receipt: install Excellent and run one task

curl -fsSL https://excellent.so/install.sh | sh

How checks decideInstall Excellent