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
Assessing a receipt separates three properties: integrity of the signed core under selected key material, authenticity of that key's organizational binding, and reproducibility of the recorded evaluation. Public fields and endpoints expose inputs to those checks, but the relying party must establish trust anchors independently.
Integrity
The issuer-operated endpoint checks the receipt commitment against its ledger view. Legacy chain.sequence and chain.previous_receipt_hash fields remain outside the signed core, so a receipt does not prove its own sequence position. Detecting a consistent chain rewrite requires an independently preserved ledger head, snapshot, timestamp, or witness.
Authenticity
Every receipt carries an Ed25519 attestation in its attestations array. A relying party can validate the signed core offline against selected public-key material. That establishes validity under the selected key, not who owns it. Establish and pin Summit's key fingerprint through a separate trusted channel before treating the result as a Summit signature.
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 | Signed core validates under selected trust material; chain position is checked separately | Signature check; externally anchored ledger comparison |
| Authenticity | Signed core validates under a key whose owner was established separately | attestations[] (Ed25519); independently authenticated key fingerprint |
| 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 operated by the issuer. A separate offline verifier can remove that API from the request path, but the relying party must still trust the exact verifier bytes, controlled JSON interpretation, signed-field set, and independently established key.
Key ownership is not the only assumption. Current offline releases have version-specific input and reporting limitations. Read the security notice, pin exact verifier bytes, and authenticate the trust-key fingerprint separately.
The honest boundary
It is worth being precise about what a verified receipt does and does not establish. A bounded result establishes only that the named checks passed under their stated inputs and trust anchors. It does not prove that recorded evidence was true, an action executed, omitted events do not exist, unsigned chain coordinates are authentic, or the record is legally admissible.
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.