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 the durable, portable artifact: a self-contained, tamper-evident record that can be stored, transmitted, and independently verified later without contacting the original caller.

The receipt is structured so that anyone holding it can answer four questions — who acted, on what evidence, against which rule, and can I trust this record has not been altered — using only the fields inside it plus the server's published public key. 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. The chain object is what makes a series of receipts tamper-evident: chain.sequence is the receipt's ordinal position, and chain.previous_receipt_hash holds the hash of the prior receipt in the chain. The first receipt in a chain has previous_receipt_hash: null and a sequence of 1. Because each receipt commits to the one before it, a single altered receipt breaks the linkage for every record that follows — you cannot quietly rewrite history without the chain failing verification.

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 asserts reproducibility. 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. Determinism is what separates a defensible decision from a one-off: if the same evidence and policy reliably produce the same verdict, the receipt is a repeatable proof rather than 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 the signatures that seal the receipt. Each entry records the signer (e.g. decrec-server), the algorithm — Ed25519 — the signature as a base64 string, and a timestamp. The signature binds the entire receipt: identity, chain, admissibility, subject, evidence, replay, and policy. Once attested, any change to any field invalidates the signature.

How the pieces lock together

The sections are not independent — they compose into something verifiable. The evidence.inputs_hash and replay.replay_hash commit to the inputs and the reproducible result; the chain.previous_receipt_hash links the receipt into an ordered, append-only history; and the Ed25519 attestations sign over the whole structure. To tamper with one field, you would have to forge the signature and re-derive every downstream hash in the chain.

Anyone can confirm this independently. Submit the receipt to POST /v1/verify and the server checks that required fields are present, recomputes the canonical hash and matches it against the ledger, and validates the Ed25519 signature against its public key. The response returns valid: true only when every check passes. For offline verification, fetch the server's public key with GET /v1/keys/server and validate the signature yourself.