Assume the store is already lost.

Prevention and detection are different security properties, they answer to different adversaries, and treating them as interchangeable is the most common error in evidential record-keeping. This paper states the threat model the rest of the series is designed against — including the part where the party writing the records is inside it.

§1The question a record actually has to answer

An operational record — of a decision a system made, of the state it was in when it made it — is usually built to answer the question what happened? That is the wrong question, or rather it is the easy half of the right one. The question that matters arrives later, from someone with an interest in the answer being different, and it is:

Every clause there is load-bearing. A party who has no reason to trust you, because the moment a record is contested, the credibility of whoever produced it is precisely what is in dispute. Satisfy themselves, because an assurance you provide is a claim, not evidence. Without your cooperation, because a check that requires your software, your servers or your permission is not a check; it is a request to be trusted, wearing the costume of a verification.

Systems designed to answer what happened and systems designed to answer that question look superficially similar — both write rows, both keep timestamps — and they differ almost entirely in their threat model.

§2Naming the adversary, including the awkward one

Threat models are usually stated too politely to be useful. Here is a blunt one. The adversary is any party who can write to the store where the records live. In practice that set includes:

• an attacker who has obtained database credentials, which is the case everyone models;
• an administrator acting outside policy, which is the case everyone has and few model;
• a migration script written under time pressure, which is the case nobody calls an adversary and which causes more silent corruption than the first two combined;
• a party under legal or commercial pressure for the record to say something else;
• and — the one that is usually omitted — the operator of the system itself.

That last inclusion is the whole design. If the operator is outside the threat model, then every guarantee in the system reduces to "the operator says so", and the record is worth exactly the operator's reputation at the moment it is questioned. Which is to say: worth least precisely when it is needed most.

Placing yourself inside your own threat model is uncomfortable, and it forces a specific discipline. It means no verification step may depend on a secret only you hold, no check may be performed only by your code, and any property you cannot demonstrate to a hostile reader is a property you should stop claiming. Most of the constructions in this series are what remains after applying that filter.

§3Why access control is necessary and not sufficient

The instinctive answer to this problem is to make the store unwritable: restrict permissions, put the data somewhere append-only, revoke UPDATE and DELETE. Do all of that — it is genuinely valuable and it raises the cost of the easy attacks. But understand what class of property it is.

Access control is a preventive control, and preventive controls share a failure mode: when they fail, they fail silently and indistinguishably from normal operation. A permission that was revoked and is now, for some reason, not revoked, produces no signal. A row rewritten by someone who legitimately holds the credential looks exactly like a row written legitimately. The system continues reporting that everything is fine, because from inside the system everything is fine.

Detection is what still works after the preventive control has failed. It does not compete with access control; it is the layer that assumes access control lost. The two together give you a system where the cheap attacks are blocked and the expensive ones are visible — which is the best available outcome, because no arrangement of software makes a database physically unwritable by someone holding its credentials.

§4Three requirements detection imposes

Once the goal is detection under the adversary in §2, three requirements follow, and each of them eliminates a large class of otherwise reasonable designs.

1 · The record must prove itself, not match a copy

A tempting design keeps a second copy of each record — a checksum table, a shadow log, a replica — and verifies by comparison. This does nothing against the adversary in §2, because a party who can write the record can write the copy. Comparison detects accidental divergence, which is a real and different problem, and it detects deliberate alteration only if the attacker forgets one of the two places.

What is needed instead is re-derivation: the check must recompute the record's identity from the record itself, using a function anyone can run, and compare against a value that is bound to that computation. Nothing is trusted because it was stored; things are trusted because they recompute.

2 · The check must be runnable by someone who does not have us

This requirement is the one that most changes engineering decisions, because it rules out anything convenient. It means the verification algorithm must be describable in a page, implemented in primitives with independent implementations, and executable with no network access, no accounts and no proprietary software. In practice it means standard cryptographic primitives, an unambiguous byte layout, and a verifier small enough that a sceptic can read it in an afternoon and rewrite it in another language to confirm it agrees.

It also means resisting a very natural feature: a verification endpoint. An API that reports whether a record is valid is worse than useless in a dispute, because its answer is the operator's assertion once again, now with an HTTP status code attached.

3 · A failure must localise

"Something in this set of records is wrong" is nearly worthless to an examining party. The check must say which record failed and which property failed of it — content, position, or attribution — because those three failures have different explanations and different consequences. Designs that hash a whole collection into one value satisfy the first two requirements and fail this one, which is a large part of why the constructions in Paper 002 are trees rather than digests.

§5What this cannot do, stated before anyone else says it

A paper that only lists what a construction achieves is marketing with citations. The limits are more informative than the capabilities, and they are structural rather than temporary:

§6Why this is becoming a practical question, not a theoretical one

The engineering above is not new; transparency logs and hash-linked records have existed for years. What is changing is the frequency with which an organisation is asked to produce an operational record to a party that has no reason to be generous about it.

One concrete example, offered for context rather than as legal analysis. Directive (EU) 2024/2853 on liability for defective products — which by Article 4(1) treats software as a product, and whose recital 13 addresses AI systems directly — applies from 9 December 2026. Its Article 9(1) requires Member States to ensure that a defendant can be ordered to disclose relevant evidence at its disposal, subject to conditions of necessity and proportionality in Article 9(3) and to the protection of confidential information and trade secrets in Article 9(4). Article 10(2)(a) provides that where a defendant fails to disclose under Article 9(1), defectiveness is presumed — a presumption the defendant may rebut under Article 10(5). Recital 46 states the purpose plainly: the presumption exists to give an incentive to comply with the disclosure obligation.^[1]

Read that as an engineer rather than a lawyer and it describes a system requirement. A record must be producible on demand, partial — because withholding what is irrelevant or confidential is legitimate and contemplated by the text — and checkable by the other side, because a disclosure the recipient must simply believe is unlikely to end the argument. Those three requirements together are not satisfied by an ordinary application log, and the tension between the second and the third is the subject of the next paper.

§7What follows from all this

Everything in the remaining papers is forced by the three requirements in §4 rather than chosen for elegance, and it is worth previewing why, because the constructions look arbitrary until you see the attack each one answers.

A record must prove itself, so its identity is derived from its content by a function anyone can run. A disclosure must remain checkable after parts are removed, so that identity cannot be a single digest over the whole — it has to be a tree over independently committed fields, and the leaves have to be salted or a low-entropy withheld value is recoverable by guessing. Failures must localise and attribution must survive, so a signature has to cover not just content but position and ownership. And because none of that detects the removal of records that were never handed over at all, something outside the system has to hold a commitment to what the whole was.

Each of those sentences is a paper. They were also, in order, four opportunities to get something subtly wrong — and the most useful parts of what follows are the places where an earlier version of this work did.