CONCEPTS

The ledger & audit chain

Each Decision Receipt carries a small chain object that links it to the receipt before it. Those links accumulate into an append-only ledger that is tamper-evident — not merely tamper-resistant — and observable by anyone.

The chain object

Every receipt returned by POST /v1/evaluate includes a chain object with two fields. sequence is the receipt's ordinal position in the ledger. previous_receipt_hash is the hash of the receipt that came immediately before it — or null for the very first receipt, which has no predecessor.

Because each receipt names the hash of its predecessor, the receipts form a single linked sequence. The hash is computed over the prior receipt's contents — its evidence, policy result, replay result, and Ed25519 attestation. Change any byte of an earlier receipt and its hash changes; the previous_receipt_hash recorded in the next receipt no longer matches, and the break is visible to anyone walking the chain.

CHAIN ACROSS TWO SEQUENTIAL RECEIPTS

// receipt N (the first entry)
"chain": {
  "sequence": 1,
  "previous_receipt_hash": null
}

// receipt N+1 — its previous_receipt_hash is the hash of receipt N
"chain": {
  "sequence": 2,
  "previous_receipt_hash": "sha256:9f2c…a17b"
}

To insert, edit, or remove receipt N undetected, an actor would have to recompute receipt N's hash, rewrite the previous_receipt_hash of receipt N+1, then re-sign receipt N+1 with the server's private key, and repeat for every receipt after it. The Ed25519 signatures make that re-signing infeasible without the server key — which is why the chain is evidence of tampering, not just an obstacle to it.

The ledger

The ledger is the collection of these hash-linked receipts. It is append-only: new receipts are added at the end, and existing entries are never rewritten. Several public, read-only endpoints expose it, most of them requiring no authentication.

GET /v1/ledger/stats reports totals such as accepted, blocked, escalated, and non_deterministic, along with the set of agents and repositories observed. Search and timeline let an auditor locate the receipts relevant to a particular agent, repository, or window; compare and diff put two records next to each other, which is how a reviewer sees how the same pull request was evaluated across successive pushes.

Append-only versus a mutable log

An ordinary application log is mutable. A line can be edited or deleted in place, and nothing in the surrounding lines records that it changed. After the fact, the log and a tampered log are indistinguishable. That is the property a hash-linked ledger removes.

Here, each entry commits to the one before it. A single edit to a past receipt is therefore not a local change — it invalidates the previous_receipt_hash of the following entry, and of every entry after that. The difference is qualitative: a mutable log can be quietly rewritten, while an append-only hash-linked record makes any edit detectable. The ledger does not promise that no one will ever try to alter a past decision; it promises that such an alteration cannot pass unnoticed.

Independent audit

Because the chain is fully observable, audit does not depend on Summit Cognitive. Anyone can pull the ledger, walk it in sequence order, and check that each receipt's previous_receipt_hash equals the hash of the entry before it. At each link they can also verify the Ed25519 attestation against the server's published public key from GET /v1/keys/server, confirming the receipt was signed by the server and has not been altered since.

That verification can run live through POST /v1/verify or entirely offline against the saved public key — no account, no trust in the auditor's tooling, only the receipts and the key. An unbroken chain of valid signatures is a self-contained proof that the sequence of decisions is intact. For the step-by-step verification procedure, see Verifying receipts; for what a single receipt contains and why it is signed, see The Decision Receipt.