How tamper-evidence works
You don't need this page to rely on the audit log. It's here because the design is worth understanding, and a guarantee you can explain is one you can trust.
Three properties, stacked — each sufficient on its own, used together anyway.
Each event is chained to the last
Every record carries a fingerprint that depends on the record before it. Change any earlier event and every fingerprint after it stops matching. A single altered row, a deleted one, a reordering — all break the chain, and the break is visible at the exact point it occurred. The history is bound to itself, link by link.
The position is witnessed off-box
The head of the chain is recorded on separate infrastructure. An attacker who fully controls one machine still can't truncate or wipe its log without the gap being noticed elsewhere — the witness remembers a position the local log can no longer account for. This is what closes the "just delete the whole log" hole that pure self-checking can't.
Anyone can re-walk it
Verification recomputes the chain from start to finish and needs no secret to do so. Integrity is checkable, not merely asserted — you, an auditor, or a regulator can run the same walk and reach the same answer, without holding any key of yours. A guarantee only you can verify isn't much of a guarantee; this one is open to anyone you choose to show it to.
Why keyless is a feature, not a weakness
The chain protects integrity — that the record wasn't changed — not confidentiality. Confidentiality of the events is handled separately, by encryption. Keeping the integrity check keyless is deliberate: it means proving the log is honest never requires exposing anything sensitive, and never depends on a key that could be lost or compromised.
> What's deliberately not on this page: the exact fingerprint construction, the witness protocol, and how records are encrypted at rest. Those are implementation. The properties are public; the mechanisms stay in — describing what's true and why it's safe, never publishing the recipe.