Audit chain

The reason to chain an audit log rather than simply append to it is that the question worth asking of one — who widened this permission, when, and did anybody edit the record afterwards — has to be answerable against your own administrators. An append-only table whose append-only property is enforced by the person being constrained is not a control: where the database is a file on that person’s disk, immutability asserted by configuration is a setting they can change and change back. Chaining does not stop them. It makes the change visible to anyone who later recomputes the digests, which is a weaker goal and an achievable one.

An entry holds the facts of one administrative act — the actor, the action, the resource, a detail payload, a timestamp — plus a sequence number, the previous entry’s digest and its own. The digest input is the previous digest, a separator, and a canonical serialisation of the entry’s content with its own digest field excluded. Canonical means object keys sorted recursively and no whitespace, so one record has exactly one encoding and two honest parties compute the same value. Excluding the row’s own digest from its own input is not fastidiousness: include it and a verifier recomputing from a stored row would be covering a field the original write never covered, so every verification would fail. The first entry links to a fixed genesis value, conventionally sixty-four zeros, and appends read the current tip and write the new entry inside the same transaction, so two concurrent writers cannot fork the chain.

Verification walks the chain and reports three distinct classes of failure, located rather than merely raised. A link mismatch means an entry no longer carries its predecessor’s digest — which is what a deletion from the middle looks like, because the row after the hole still points at something that is no longer there. A content mismatch means an entry was altered. A sequence gap means a row was removed, including a missing prefix: deleting entry 1 and recomputing the remainder from genesis would otherwise leave a chain that begins at 2 and checks out link by link. Sequence numbers should come from a counter that an ordinary delete does not lower, so a removal leaves a hole that no amount of re-hashing can close, and the result should name the first sequence at which the chain breaks. The difference between an investigation and a shrug is that number.

Two consequences shape how the chain gets used. Verification is linear in the length of the chain and gets slower every day, which is managed by walking in bounded chunks that yield to other work, caching a verdict for a few seconds and refusing to run overlapping walks — not by pretending the cost is not there. And entries genuinely cannot be edited afterwards, which is the design working and is also a constraint on what belongs in them: an erasure that touches a detail field breaks verification from that sequence onward. Keep the chain to governance-plane facts — an agent registered, a permission widened, a kill switch engaged, an approval decided, an evidence bundle exported — and keep request payloads in a separate table with no foreign key between them. That separation is what lets a data subject’s records be deleted while chain verification still passes, and what lets the record that a deletion happened outlive the deleted data.

What the chain does not do should be stated in the same breath as what it does. On its own it is evidence only against a party who cannot recompute it; whoever can write every row can rewrite an entry and re-hash everything downstream, and the result verifies clean. Truncation with nothing appended afterwards leaves every remaining link honest, so a shortened chain also verifies clean, and nothing inside the store can fix that — the length has to have been attested somewhere the same operator cannot edit. A chain is not a Merkle tree either: there are no inclusion proofs, so a verifiable subset cannot be handed to a regulator without handing over the rest of the log.