CONCEPTS
The trust model
A record is usually only as trustworthy as whoever issued it. A Decision Receipt is built to invert that: it lets a relying party trust a decision by checking properties it can verify directly, rather than by trusting the good faith — or the reputation — of the party that produced it.
The problem: trust that rests on the issuer
Most audit records ask the reader to take the issuer at their word. A log line, an approval note, a screenshot of a passing build — each is believable only to the extent that you believe whoever wrote it did so honestly, completely, and without later editing it. The record carries no independent evidence of its own integrity. If the issuer is mistaken, compromised, or motivated to misrepresent what happened, the record is worth no more than the issuer is.
For a consequential action taken or assisted by an autonomous agent — a merge, an infrastructure change, an access grant — that is a weak foundation. The relying party is often a different organization, a regulator, or a future reviewer with no relationship to the issuer and no reason to extend trust on reputation alone. A Decision Receipt is designed so that none of that trust is required. The properties that make the receipt believable are observable, public, and checkable by anyone holding the receipt.
Three checkable pillars
Trust in a receipt rests on three independent properties. Each is backed by a public mechanism and a public field or endpoint, so the relying party can confirm it without privileged access and without asking the issuer to vouch for anything.
Integrity
The receipt has not been altered, and it sits in its proper place in a sequence. Verification recomputes the receipt's canonical hash and matches it against the ledger — the hash_integrity check in POST /v1/verify reports exactly this. Receipts are also hash-chained: each carries a chain.sequence and a chain.previous_receipt_hash linking it to the one before. Tampering with a receipt, or removing one from the chain, breaks the recomputed hash or the chain linkage, and the break is detectable by anyone who checks.
Authenticity
The receipt was signed by the server that claims to have issued it. Every receipt carries an Ed25519 attestation in its attestations array. The server's public key is published at GET /v1/keys/server in PEM format. A relying party can verify the signature against that key with any standard Ed25519 library — offline, with no call back to Summit, and no need to trust the network path the receipt arrived over. A signature that does not verify against the published key did not come from the server.
Reproducibility
The decision can be re-derived rather than taken on faith. The receipt records replay determinism — replay.deterministic and a replay_hash — capturing that the same evaluation, run again against the same evidence, produced the same result. A relying party does not have to accept the verdict because it was asserted; the receipt states that it is reproducible, and that property is itself part of what is signed and hashed.
| Pillar | What it establishes | Backed by |
|---|---|---|
| Integrity | Receipt is unaltered and correctly chained | hash_integrity check; chain.sequence, chain.previous_receipt_hash |
| Authenticity | Receipt was signed by the issuing server | attestations[] (Ed25519) verified against GET /v1/keys/server |
| Reproducibility | The decision can be re-derived, not just asserted | replay.deterministic, replay_hash |
What a relying party does not have to trust
Because the three pillars are checkable, a relying party can set aside several things it would otherwise have to assume.
- The issuer's good faith. A receipt that verifies is sound whether or not the issuer is acting honestly; one that has been altered fails the integrity check regardless of who altered it.
- The network. The Ed25519 attestation is verified against a public key, so a receipt that arrived over an untrusted channel — forwarded, archived, pasted into a ticket — is exactly as verifiable as one fetched directly.
- Summit's own API.
POST /v1/verifyis a convenience that runs the checks for you. The authenticity check needs only the receipt and the server's public key; it can be performed entirely offline. The relying party is not asked to trust the verifier in order to trust the receipt.
The only thing the offline check assumes is that the published Ed25519 public key genuinely belongs to the server. That key is fetched once from GET /v1/keys/server and can be pinned; every subsequent verification is local.
The honest boundary
It is worth being precise about what a verified receipt does and does not establish. A receipt that passes all three pillars establishes that a specific decision was evaluated against stated evidence and an explicit policy, that the evaluation is reproducible, and that the result was authentically attested by the server. That is a strong claim, and it is exactly the claim the relying party can check.
It is not a claim that the decision was correct. A verified receipt does not establish that the policy applied was the right policy, nor that the evidence cited was true. Those remain matters of judgment for the reviewing party — which is precisely why the evidence is recorded explicitly, with its types, confidence scores, and provenance, and why the policy result is recorded rule by rule. The receipt does not ask you to accept its conclusions; it gives you the material to contest them. Trust in the receipt's integrity is mechanical and checkable; trust in the decision's wisdom remains where it belongs, with the reviewer.
For the surrounding concepts, see the Decision Receipt and decision admissibility for what a receipt records and why; the ledger and audit chain for how receipts are sequenced and hash-chained; and the guide on verifying receipts for the practical steps, online and offline.