CONCEPTS
The ledger & audit chain
Each Decision Receipt carries a small chain object that describes its claimed ledger position and predecessor. These links are observable and structurally checkable, but legacy receipt signatures do not cover the chain coordinates. Tamper evidence therefore requires an independently anchored ledger view, not a receipt alone.
For deployed receipts using signed_fields: receipt-core-v1, chain.sequence and chain.previous_receipt_hash sit outside the signed core. A structurally matching link is not cryptographic proof of ledger position. See the offline verifier security notice.
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.
| Field | Type | Description |
|---|---|---|
sequence | integer | Ordinal position of the receipt in the ledger |
previous_receipt_hash | string | null | Hash of the prior receipt; null for the first entry |
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"
}A reviewer can detect a changed predecessor when comparing a receipt sequence against an independently preserved ledger snapshot or witness. The legacy signature alone does not prevent an actor who controls the ledger representation from rewriting unsigned chain coordinates consistently. The cryptographic signature protects the signed receipt core; external anchoring protects claims about sequence position.
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.
?q=, ?agent=, ?repo=, ?verdict=?repository=?ids=id1,id2?repository=&pr=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.
Each entry names the hash of the one before it, so a past edit causes later links to diverge from an earlier anchored view. Without such an anchor, a consistently rewritten sequence can remain structurally self-consistent. The ledger's append-only operation and external snapshots or witnesses are therefore separate controls from the receipt signature.
This page describes the observable chain fields and how to compare them. It does not claim that legacy chain coordinates are signed or that a receipt can prove its own ledger position.
Independent audit
Anyone can pull the ledger and check structural continuity in sequence order. To make that review independent of Summit, preserve or obtain a ledger head, timestamp, or witness from a separate trusted channel. Separately, verify each signed core against an independently established public-key fingerprint.
Neither a structurally unbroken chain nor a set of valid receipt signatures is a self-contained proof of sequence integrity under the legacy signing contract. For the bounded signature procedure, see Verifying receipts; for what a single receipt contains, see The Decision Receipt.