Documentation

Attestation and audit ledger

What is signed, what is reconstructed, and what verification actually proves.

Two different records

These are frequently conflated, so they are stated separately. The attestation chain is append-only and hash-linked, and covers the proposal, policy decision, approval, and execution loop. The broader incident history — detection, diagnosis, tests, decisions, outcomes, time-to-resolution — is reconstructed relationally from incident, fix, and decision records, not from a single global event log.

Both are real. Only the first is cryptographically chained, and only the first is what “tamper-evident” refers to.

What is signed

DSSE envelopes wrapping in-toto Statements, signed with Ed25519, with one keypair per role: agent, policy engine, human approver, and executor. Each entry’s signed parent hash must equal the previous envelope’s own hash, so insertion, deletion, reordering, or edit breaks a signature rather than merely a foreign-key reference. Denied proposals get their own signed chain, which terminates at the denial and never grows an execution event.

Approvals are always attributed to a named human. Caretaker is never recorded as the approver.

What verification proves

That the rows carry valid signatures from the trusted keys and form an intact hash chain — nobody edited a row without holding the relevant key. It does not prove the chain was never wholesale replaced by someone who also holds the keys or controls the trust map, because the rows and the trust policy currently live in the same database.

The ledger is therefore tamper-evident. It is not independently verifiable, and it is never tamper-proof. See What a signed, hash-linked ledger does and does not prove.