CONCEPTS

Anatomy of a Decision Receipt

A Decision Receipt is the object returned in the receipt field of POST /v1/evaluate. It records what an agent did, what it was decided on, whether the decision was reproducible, how it scored against policy, and a cryptographic seal binding all of that together. This page walks through each top-level section and what it asserts.

What a receipt is

Every call to POST /v1/evaluate returns an envelope containing the original claim, the decision, the policy verdict, the replay result, and a receipt. The receipt is a durable, portable record that can be stored and transmitted. A recipient can later check its signed core offline against independently pinned public-key material without contacting the original caller.

The receipt is structured to record four questions — who was named as actor, what evidence was presented, which rule was applied, and does the signed core validate under independently established key material. The receipt does not prove those recorded facts by itself. Below is an abridged receipt drawn from the API reference example.

RECEIPT (ABRIDGED)

{
  "receipt_id": "dr-...",
  "chain": {
    "sequence": 1,
    "previous_receipt_hash": null
  },
  "admissibility": {
    "status": "ACCEPTED"
  },
  "subject": {
    "agent": "claude-code",
    "repository": "acme-corp/widget-api",
    "pull_request": 42
  },
  "evidence": {
    "inputs_hash": "sha256:...",
    "source_count": 2,
    "source_types": ["ci", "code_review"]
  },
  "replay": {
    "deterministic": true,
    "replay_hash": "sha256:..."
  },
  "policy": {
    "status": "PASS",
    "checks": []
  },
  "attestations": [
    {
      "signer": "decrec-server",
      "algorithm": "Ed25519",
      "signature": "base64-encoded-signature...",
      "timestamp": "2026-05-30T10:35:00.000Z"
    }
  ]
}

The fields, section by section

receipt_id and chain — identity and the hash chain

The receipt_id (e.g. dr-...) is the stable handle for this record. chain.sequence states the claimed ordinal position, and chain.previous_receipt_hash states the claimed predecessor hash. Under the deployed legacy signing contract those coordinates are outside the signed core. They support structural comparison against an independently anchored ledger view; they do not let a receipt prove its own sequence position.

admissibility — the headline status

The admissibility.status field is the receipt's single most important summary. It takes one of three values:

• ACCEPTED — the claim met the admissibility bar: evidence sufficient, policy satisfied, replay deterministic.
• NON_DETERMINISTIC — the action could not be reproduced reliably, so the record cannot stand as a clean proof.
• REJECTED — the claim failed admissibility outright.

Admissibility is distinct from the policy verdict (ALLOWED / BLOCKED / ESCALATED) that appears at the top level of the evaluate response: the verdict is the rule outcome, while admissibility is whether the record itself qualifies as trustworthy evidence.

subject — who and what acted

The subject object names the actor and target. subject.agent identifies the agent that performed the action (for example claude-code), subject.repository is the repository acted on, and subject.pull_request is the PR number. This is the "who did what, where" line — the part a reviewer reads first to know which action a receipt pertains to.

evidence — what it was decided on

The evidence object summarizes the inputs that fed the decision. evidence.inputs_hash is a hash over those inputs, so the exact evidence set is committed to without embedding it all in the receipt. evidence.source_count records how many evidence sources were supplied, and evidence.source_types lists the distinct kinds (e.g. ["ci", "code_review"]). Together these let a verifier confirm the decision rested on the breadth of evidence claimed — and that the inputs have not changed since.

replay — reproducibility

The replay object records a reproducibility assertion. replay.deterministic is true when re-evaluating the same inputs yields the same outcome, and replay.replay_hash is the hash of that replay result. If the same recorded evidence and policy produce the same verdict, the receipt carries a repeatable check rather than only a snapshot of a single run.

policy — the rule result

The policy object carries the rule outcome as it applies to the receipt. policy.status is PASS when the configured checks were satisfied, and policy.checks is the list of individual check results — empty here because every check passed cleanly. This is where you see why a claim was admitted or not, in terms of the policy that was in force.

attestations — the cryptographic seal

The attestations array holds signatures over the declared signed-field set. Each entry records the signer label, the algorithm — Ed25519 — the signature as a base64 string, and a timestamp. Under receipt-core-v1, the signature binds the canonical signed core, not every field in the surrounding receipt JSON. Changes inside that core invalidate the signature; legacy chain coordinates require a separate anchor.

How the pieces lock together

The signed core binds the fields named by the receipt's signing contract, including the committed evidence and replay values. Legacy chain coordinates are separate and must be checked against an external ledger anchor. Always inspect the declared signed-field set instead of assuming the attestation covers the whole JSON object.

POST /v1/verify reports the issuer-operated checks it performs. For a bounded offline check, use controlled input and key material whose Summit identity was established separately; fetching a key from the issuer is availability, not independent identity proof. See Verifying receipts and the linked security notice.