Tamper-evident, append-only, and tamper-proof

Append-only describes a discipline

Append-only means the store adds rows and does not edit them. Corrections arrive as new rows that supersede old ones rather than as updates in place, so the history stays readable.

This is genuinely useful. It means a record cannot quietly change shape between when you read it and when someone else does, and it means "what did we believe on Tuesday" is answerable.

What it does not mean is that the rows are true. Append-only is a statement about how writes behave, not about whether what was written was correct. A system that confidently records an action that never happened, append-only, has preserved a false record perfectly.

It is also a property of the application, not usually of the storage underneath. Whoever has write access to the database can still edit a row in an append-only table. The discipline holds until someone steps around it.

Tamper-evident means you would find out

Tamper-evident means alteration leaves a mark. The usual mechanism is hash-chaining: each record includes a hash covering the record before it, so changing an old entry breaks every hash after it, and the break is detectable by recomputing the chain.

This is a real, meaningful guarantee and it is cheap to implement. It converts "somebody edited history" from an invisible event into a detectable one.

Its limit is precise and worth stating plainly: whoever can rewrite the records can usually also recompute the chain. Detection only works if the head of the chain — the most recent hash — is somewhere they cannot reach. If the head lives in the same database as the records, an attacker with write access rewrites both and the chain verifies cleanly against its own tampered head.

Claritty’s ledger is hash-chained and the head has never left our own infrastructure. So sealing today proves the ledger agrees with itself, and proves nothing at all against anyone who can rewrite the seals. Publishing the head somewhere independent is the step that would change that, and it has not been taken.

Tamper-proof is the one to be suspicious of

Tamper-proof means alteration is impossible. For a record held in a system its operator controls, that is not achievable, and a vendor claiming it is either using the word loosely or has not thought about their own privileged access.

The honest versions are narrower. Write-once storage with a retention lock makes deletion impossible for a defined window, enforced by the storage provider rather than by the application. Publishing a hash to an independent party makes rewriting detectable by someone who is not you. Both are real. Neither is "tamper-proof" in the sense the word implies.

The word is common enough in this category that it is worth treating as a signal. A page that says tamper-proof has usually not distinguished the three ideas on this page, which means its other guarantees deserve the same scrutiny.

Which one you actually need

It depends entirely on who you are defending against, and that question is usually skipped.

If the risk is honest error — a system recording something wrong, a person misremembering — append-only plus good records is most of the answer, and re-verification against the source system is the rest.

If the risk is a dispute where someone might benefit from the record reading differently, tamper-evidence starts to matter, and where the chain head lives becomes the load-bearing detail rather than an implementation note.

If the risk is a determined insider with production access, none of the above is sufficient on its own, and you are into independent custody: publishing hashes outside your control, or write-once storage you cannot yourself unlock. Most teams do not need this. The ones who think they might should ask their vendor exactly where the head is kept, and treat a vague answer as an answer.