CONCEPTS
Decision admissibility
A consequential decision — especially one made or assisted by an autonomous agent — should be judged not only by whether it was permitted, but by whether it can be reconstructed, reviewed, and contested after the fact. That property is what the Decision Receipt API calls admissibility.
Authorized is not the same as admissible
Most systems that govern agent behavior ask one question: was this action authorized? A token was valid, a role had the permission, a policy returned true. Authorization is necessary, but it is shallow. It tells you a gate opened. It does not tell you why, on what evidence, or whether a reviewer six months from now could look at the same inputs and reach the same conclusion.
Admissibility asks a deeper question, borrowed from a domain that has been refining it for centuries. Courts do not admit every fact a party wishes to introduce. Evidence must be relevant, it must be authenticated, its origin must be traceable, and its handling must survive scrutiny. There are rules about what is allowed to decide a question precisely because the stakes of deciding wrongly are high. Machine-learning evaluation, for the most part, forgot those rules: a model output was accepted because it was produced, not because it was shown to be admissible.
As autonomous agents begin to merge code, change infrastructure, and grant access, the gap matters. An action can be perfectly authorized and still be indefensible — because no one can later reconstruct the basis on which it was taken. Admissibility closes that gap by making the basis a first-class, verifiable artifact.
What makes a decision admissible
In the API's terms, an action is admissible when three conditions hold together. None is sufficient alone.
- Sufficient, typed, provenanced evidence. The action is supported by evidence sources that are explicitly typed — a CI run, a code review, a test result, a human approval — each carrying a confidence score and chain-of-custody provenance describing when it was captured, by what collector, and through whose hands. Evidence without provenance is an assertion, not a record.
- It passes policy. The evidence is measured against an explicit policy: a minimum number of sources, a minimum number of distinct source types, a confidence floor, whether provenance is required, whether a human must be in the loop. The policy result is recorded as a verdict — ALLOWED, ESCALATED, or BLOCKED — with the per-rule reasoning that produced it.
- It replays deterministically. Given the same evidence, the same evaluation must produce the same result. Replay determinism is what separates a reproducible judgment from a one-time coincidence. A decision that cannot be replayed cannot be defended.
When all three hold, the evaluation produces a signed receipt whose admissibility status is ACCEPTED. When replay does not reproduce the result, the receipt is marked NON_DETERMINISTIC. When the evidence or policy fails outright, it is REJECTED. The status is never hidden: an inadmissible decision is recorded as inadmissible, which is itself a useful and honest signal.
From principle to receipt
The abstract idea maps directly onto the observable fields of a Decision Receipt. Each clause of the definition above corresponds to a section of the record you can read, store, and independently verify.
| Receipt section | What it attests |
|---|---|
evidence | The typed, provenanced sources that supported the action, summarized by source count, source types, and a hash of the inputs. |
policy | The verdict and the per-rule checks that produced it — the record of why the decision passed or failed. |
replay | Whether the evaluation was deterministic, fixed by a replay hash that re-running the same inputs must reproduce. |
attestations | An Ed25519 signature over the receipt, naming the signer, algorithm, and timestamp — turning the claim into a cryptographically attested one. |
chain | The receipt's sequence number and the hash of the previous receipt, linking each decision into a tamper-evident chain. |
Because the receipt is signed and hash-chained, admissibility is not something you have to take on trust. Anyone holding a receipt can confirm it independently — by submitting it to POST /v1/verify, or offline against the server's published Ed25519 public key from GET /v1/keys/server. Verification recomputes the canonical hash, matches it against the ledger, and validates the signature. The decision, in other words, carries its own defense.
Why this matters now
Agents now take actions whose consequences outlast the conversation that produced them. A merged pull request ships; a granted permission persists; an infrastructure change propagates. When something later goes wrong — or when a regulator, an auditor, or a colleague simply asks "on what basis did this happen?" — authorization logs answer the wrong question. They show that a gate opened. They cannot reconstruct the evidence, replay the judgment, or prove the record has not been altered since.
Admissibility is the discipline of producing decisions that can answer the right question. It does not slow an agent down or second-guess its competence; it requires only that each consequential action leave behind a record sufficient to reconstruct, review, and contest it. The Decision Receipt API is the concrete expression of that discipline — a way to make an agent's decisions admissible by default, and verifiable by anyone.