Skip to content

Reference

Sample receipt

A real signed receipt, field by field: what each part binds, how to verify it, and what a valid signature does and does not establish.

On this page

A receipt is what a verification leaves behind. It binds the work, the evidence, the policy and the verdict into one document, hashes that document canonically, and signs the hash. Its purpose is that you do not have to trust the machine that produced it.

The document below is a real receipt, taken verbatim from the tamper-test fixtures that ship with the product. It is a synthetic experiment rather than a customer's codebase — it is genuine output of the receipt pipeline, not a hand-written example, and its signature is genuine.

One caveat, stated because this page is about checking things. The signature is real, but this sample predates the current envelope, so it does not pass today's verifier end to end. Its publicVerification block carries no parentReceiptId, and today's verifyReceiptEnvelope compares that field, so this exact document returns public-metadata-mismatch rather than a clean pass. It remains accurate as an illustration of the shape, which is what this page is for. For a pack that verifies cleanly against the current code, with a verifier you can run yourself, see the receipt format.

The document

{
  "schemaVersion": 1,
  "serviceVersion": "2026-08-16.v1",
  "receipt": {
    "schemaVersion": 1,
    "id": "receipt_exp_v0_proof_cand_v0_proof",
    "tenantId": "tenant_v0_proof",
    "runId": "run_exp_v0_proof",
    "parentReceiptId": null,
    "status": "PASS",
    "checkResultIds": [
      "check_lift_lcb",
      "check_guardrail_no_regression"
    ],
    "evidenceHashes": [
      "sha256:4cc440346439992ea6f99bb0d40f78ad63afc2dc5685208c762c720ec062772d"
    ],
    "policyVersionRefs": [
      "policy_v0_gate@2026.08"
    ],
    "engineVersion": "v0-experiment-engine@1",
    "issuedAt": "2026-08-24T12:00:00.000Z",
    "signature": {
      "keyId": "v0-ed25519-2026-08",
      "algorithm": "ed25519",
      "value": "ed25519:mLvUSNvhPOAieBlOHI3Ev_os6c0ICAKmzNCkaxHLfyyEd9c_4HM31lBH-bzKAU4E9Y43SNWkaYwHp7TJ2YKZAQ"
    }
  },
  "binding": {
    "predicate": "excellent.verification.agent-work-receipt.v1",
    "workItemId": "work_v0_proof",
    "workSnapshotId": "wsnap_v0_proof",
    "attemptId": "attempt_v0_proof",
    "runManifestId": "runman_v0_proof",
    "contractId": "contract_v0_gate",
    "evidenceSnapshotId": "evsnap_v0_proof",
    "evidenceGraphDigest": "sha256:c20e3a774dfd79d269754c556685c6b68142db819465295a2bce27cca8ddb711",
    "obligationResultIds": [
      "obligation_lift_lcb_met",
      "obligation_no_guardrail_regression"
    ],
    "evaluatorRefs": [
      "evaluator:evidence-integrity",
      "evaluator:paired-bootstrap"
    ],
    "determinationId": "determination_v0_proof_PASS",
    "validityStateId": "validity_v0_proof",
    "enforcementDecisionId": "enforcement_v0_proof_promote",
    "enforcementEffectIds": [
      "effect_promote_candidate"
    ],
    "reviewDecisionIds": [
      "review_v0_proof"
    ],
    "outcomeObservationIds": [
      "outcome_lift_confirmed"
    ],
    "auditEventIds": [
      "audit_v0_issue"
    ],
    "buildRef": "sha256:d1b984680bf2c02387e05329cb7edee163174f7847dbdc256435b945523f29b3",
    "subject": {
      "treeHash": "git-tree:a8dadc372527742ce340af91801eb1e2cd37a610e79143de7e6476dd6c917fb2",
      "commitSha": "commit:v0proof0001",
      "buildId": "build:v0-proof",
      "imageDigest": "sha256:image_f914ba9f1114edf8",
      "tenantId": "tenant_v0_proof",
      "environmentId": "env_v0_sandbox",
      "policyDigest": "policy_v0_gate@2026.08"
    },
    "experimentId": "exp_v0_proof",
    "candidateId": "cand_v0_proof",
    "agentVersionDigest": "sha256:1d3697d7c49a9e80b2276f210080e1b294bf90cb99d0c0d83f521e38ebfe4f95",
    "observedLiftPct": 25,
    "liftLcbPct": 15.625,
    "methodVersion": "paired-bootstrap@1"
  },
  "payloadHash": "sha256:a2406a65ed5fe62899a2de3abe1b2d8f3bc24a3cb19d2d6304350891022369a6",
  "signature": {
    "keyId": "v0-ed25519-2026-08",
    "algorithm": "ed25519",
    "value": "ed25519:mLvUSNvhPOAieBlOHI3Ev_os6c0ICAKmzNCkaxHLfyyEd9c_4HM31lBH-bzKAU4E9Y43SNWkaYwHp7TJ2YKZAQ"
  },
  "publicVerification": {
    "algorithm": "sha256",
    "payloadHash": "sha256:a2406a65ed5fe62899a2de3abe1b2d8f3bc24a3cb19d2d6304350891022369a6",
    "signatureAlgorithm": "ed25519",
    "keyId": "v0-ed25519-2026-08",
    "receiptId": "receipt_exp_v0_proof_cand_v0_proof",
    "runId": "run_exp_v0_proof",
    "tenantId": "tenant_v0_proof",
    "issuedAt": "2026-08-24T12:00:00.000Z"
  }
}

What each part is for

receipt is the verdict itself. status is one of the six verification states. checkResultIds names every check that was folded into it, evidenceHashes pins the evidence those checks read, and policyVersionRefs pins the policy version they were judged under. parentReceiptId is null here; on a re-verification it points at the receipt this one supersedes, because receipts are append-only and a verdict is never edited in place.

binding is the part that makes the verdict mean something. It names the exact work item, attempt, contract and evidence snapshot, plus evaluatorRefs — which evaluators decided — and subject, which pins the artifact: a git tree hash, a commit, a build id, an image digest, an environment. Without the binding, a PASS is a verdict about nothing in particular.

payloadHash is sha256: plus the hex sha256 of the canonical JSON of a fixed field list. Canonical means object keys sorted with localeCompare, no whitespace, and undefined-valued keys omitted. The profile is excellent.canonical-json.v1: non-finite numbers are rejected and timestamps require an RFC 3339 offset.

signature is Ed25519 over the ASCII bytes of that payloadHash string, base64url-encoded behind an ed25519: prefix. Ed25519 is the authoritative algorithm. Older HMAC receipts remain verifiable, but only as legacy read-only records — an HMAC key cannot be upgraded into an Ed25519 key by self-declaration.

publicVerification restates what a third party needs in order to check the signature without parsing the rest.

Verifying it

Real output, verifying this exact document:

$ node scripts/lib/offline-receipt-verifier.mjs sample-receipt.json sample-public-key.pem
{
  "receiptId": "receipt_exp_v0_proof_cand_v0_proof",
  "tenantId": "tenant_v0_proof",
  "keyId": "v0-ed25519-2026-08",
  "signatureAlgorithm": "ed25519",
  "payloadHashMatches": true,
  "recomputedPayloadHash": "sha256:a2406a65ed5fe62899a2de3abe1b2d8f3bc24a3cb19d2d6304350891022369a6",
  "signatureValid": true,
  "tamperedSignatureRejected": true,
  "tamperedContentRejected": true,
  "excellentReachable": false,
  "excellentResolutionError": "ERR_MODULE_NOT_FOUND"
}

excellentReachable: false is not a problem — it is the point. The verifier resolved nothing from Excellent and reached its answer anyway.

Now the same file with a single byte of the payload changed. Real output:

$ node scripts/lib/offline-receipt-verifier.mjs tampered-receipt.json sample-public-key.pem
{
  "receiptId": "receipt_exp_v0_proof_cand_v0_proof",
  "tenantId": "tenant_v0_proof",
  "keyId": "v0-ed25519-2026-08",
  "signatureAlgorithm": "ed25519",
  "payloadHashMatches": false,
  "recomputedPayloadHash": "sha256:2c18c3c7cc2de4fdabe5f6d102efee6bc105efa1825b91c514b342c3b46cdbb6",
  "signatureValid": true,
  "tamperedSignatureRejected": true,
  "tamperedContentRejected": true
}

The signature is still a valid signature — of the original payload. The recomputed hash no longer matches it, so the document has been altered. Read the booleans, not the exit code: the verifier exits 0 whenever it reached an answer, including a negative one, and exits 2 only when it could not reach one at all.

The zero-dependency verifier above is a script in the Excellent monorepo, useful because it runs on a machine that has never installed Excellent. The shipped CLI equivalent is excellent-mcp receipt verify <pack.json> --pubkey <key.pem>, which expects the newer offline-pack envelope rather than the receipt shape above. (Note the excellent-mcp prefix: the shorter excellent receipt verify is a different command that rejects --pubkey.) For a pack that verifies against the current envelope, see the receipt format.

What a valid signature does and does not establish

A valid signature means 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 the tenant's key. If you obtained the key from the same system that issued the verdict, a forged receipt re-signed under an attacker's key verifies exactly as cleanly as a genuine one. Confirm the key's fingerprint through a channel this system does not control, then pin it — that is what --pubkey is for.

Fetch a tenant's published trust material with:

excellent-mcp verification universal-trust-root --json
← Back to docs