How does an append-only, tamper-evident store answer repudiation, and why is it not tamper-proof?

## Why repudiation lands on data stores A store's job is remembering. If the only representation of a fact is a row that gets updated in place, then the past is whatever the row says now, and anyone with write access can make yesterday different. That is a repudiation threat against a store: not that data was stolen, but that **what the system said at the time is no longer knowable**, so any claim about it becomes one person's word against another's. In a laboratory system, a released result that can be amended in place with only the current value retained means nobody can show what the clinician actually received. The technician who changed it can deny the original value; equally, an honest technician cannot clear themselves. Both halves of the repudiation threat are live. ## Append-only: keep history, project the present The first control is structural. Model the record as an **immutable sequence of entries**: - the original release, with author, time and content; - the amendment, as a **new** entry carrying author, time, the new content and a reason; - deletion expressed as a tombstone entry, never as a removed row. The "current result" becomes a view computed over the sequence. This alone removes the silent overwrite, and it also gives you something the dispute actually needs: the *reason* an amendment was made, captured at the moment it was made rather than reconstructed afterwards. Note that append-only is a property you have to design for. A history table filled by whatever also has write access to the live row is only as append-only as the permissions around it. ## Tamper-evidence: chaining Append-only stops accidental and casual overwrites. It does not stop someone with write access from editing an old entry. Tamper-evidence addresses that by making each entry commit to its predecessor - the entry stores a hash computed over the previous entry's hash plus its own payload: ``` seq 1 payload A prev = 0000 hash = H1 seq 2 payload B prev = H1 hash = H2 seq 3 payload C prev = H2 hash = H3 <- head ``` Verification walks the chain and recomputes. Change payload B and H2 no longer matches what entry 3 stored as its `prev`, so the break points precisely at the edited entry. This is genuinely useful: it converts an invisible edit into a visible one and localises it. ## Why it is evident, not proof The honest limitation, and the part interviewers probe: whoever can rewrite entry 2 can normally also recompute H2, H3 and every later hash. A self-contained chain in a store one administrator fully controls proves very little against **that** administrator. Two further problems: - **Truncation.** Deleting the newest entries leaves a perfectly valid chain. Nothing internal reveals that entries 198-200 ever existed. - **Silence.** An attacker who simply stops the writes produces no broken hash at all; the absence of entries is the attack, and absence is invisible unless the design expects presence. ## What turns evidence into proof 1. **Witness the head outside the trust boundary.** Periodically copy or publish the current head hash and sequence number to a place the operators of the store cannot administer - a separate account or organisation, a counterparty, a signed periodic attestation. Now a rewritten chain contradicts an external record, and truncation is detectable because the external sequence number is higher. 2. **Ship entries continuously across a boundary.** A near-real-time copy in a store under different administrative control means an edit has to be made in two places by two different administrator populations. 3. **Sign with a key held elsewhere.** If entries are signed by a key the store's operators do not hold, they cannot forge replacements even if they can delete. 4. **Use write-once retention where it exists.** Retention-locked, write-once storage is a genuinely **preventive** control, whereas a hash chain is detective - the distinction is worth stating explicitly, because conflating the two is the classic error here. 5. **Make silence visible.** Monotonic sequence numbers and periodic heartbeat entries mean a gap or a stopped stream is itself an observable fact of the record rather than nothing at all. 6. **Separate duties.** The evidence store must not be administered by the population it holds accountable. That separation is what makes the record credible to a third party, and it is a modelling decision, not an implementation detail. ## Verify, and keep only what you need A chain nobody ever verifies is decoration. Verification should run on a schedule and on demand during a dispute, and someone must own what happens when it fails. And because these records live for years, apply data minimisation deliberately: keep the fields that settle disputes, and where the payload itself is sensitive, store a hash of it plus a pointer rather than the content, so the evidence store does not quietly become the most attractive copy of the data you own. ## What goes in the threat model For each store whose history could be disputed, record three things: the answering control (append-only, chained, witnessed, retained for N years), **who could defeat it**, and how a break would ever be noticed. The second and third are what distinguish a modelled control from a checkbox.