What is a tamper-evident audit log?
A tamper-evident audit log is a record of events where any alteration — inserting, deleting, or editing an entry — is detectable by anyone who checks, not just by the party that owns the log. That is the whole distinction from an ordinary log. An ordinary log is mutable and trust-based: anyone with write access can change a past entry, and nothing about the log itself proves it wasn't changed. You are asked to believe it.
“Tamper-evident” is a deliberately humble claim. It does not mean tamper-proof — you cannot stop someone with access from trying to alter records. It means tampering cannot happen silently: the moment a record is touched, verification fails and the alteration is exposed. For audit and compliance that is the property that matters, because the threat is not only an outside attacker but a future dispute over what the record actually said. Two mechanisms produce it together: a hash chain and a signature.
How does a hash chain make tampering detectable?
A hash function takes any input and returns a fixed-size fingerprint; change one byte of the input and the fingerprint changes completely and unpredictably. A hash chain uses that property to link records: each entry includes the hash of the entry before it. Entry 2 commits to entry 1, entry 3 commits to entry 2, and so on, so the records form a chain where every link depends on its whole history.
The consequence is exactly what you want. Alter any past entry and its hash changes; that breaks the hash stored in the next entry, which breaks the one after that, all the way to the head. There is no way to quietly edit record 50 in a chain of 1,000 without recomputing every record from 50 onward — and if the head of the chain is published or signed, even that is caught. Verification is mechanical: walk the chain, recompute each hash, confirm each entry's stored “previous hash” matches. Tampering stops being something you hope didn't happen and becomes something the math reveals.
What does the signature add that the hash chain doesn't?
A hash chain proves integrity — the records weren't altered after the fact — but it says nothing about origin. A chain you computed yourself is internally consistent and still proves nothing to me, because I have no reason to believe you didn't compute the whole thing this morning. That is the gap a signature closes.
An ed25519 signature is public-key cryptography: the holder of a private key signs the exact bytes of a record (in practice, the head of the chain), and anyone holding the matching public key can verify that those exact bytes were signed by that key. No shared secret changes hands, and no trusted third party is needed — verification is a local computation anyone can run. Integrity (hash chain) plus origin (signature) is the complete property: the record wasn't altered, and it provably came from the key that was supposed to produce it.
Why “signed, not logged” — and can you verify ours?
“Signed, not logged” is shorthand for the difference between an assertion and a proof. A logged claim asks for trust: here is our audit trail, take our word that it's accurate. A signed, hash-chained claim offers verification: here is the trail, here is the public key, check it yourself. The distance between those two sentences is the entire distance between a governed control plane and an ungoverned one — it is the verifiable evidence property, made concrete.
This is the bar we hold ourselves to rather than just describe. The deploys that carry this layer — including this site — are recorded in an append-only, hash-chained trail and signed with ed25519, and the check runs in your browser against the live endpoint, with no libraries and nothing to trust but the math. A governance layer that can't demonstrate its own claims is just more assertion. Capability and classification are the other two properties of the same control plane: see capability declaration and EU AI Act classification, and the practice behind them in AI governance & evidence.