Skip to content
← All insights
Operating MemoryMAR 13, 20264 min read

Evidence is append-only, or it is not evidence

A record that can be quietly edited is a record of what someone currently believes. Contradiction should require counter-evidence, not a revision.

Algodyne

If a claim and its supporting record can both be revised after the fact, the record has stopped being evidence and become a summary of the present view. It will always agree with whoever last touched it, which makes it useless for the single job evidence has: telling you something you no longer want to hear.

So the log only grows. To contradict a prior claim you submit new evidence carrying greater weight, and the original persists alongside it. The pair is more informative than either alone, because the interesting object is usually not the current belief but the moment it changed.

Deletion, and the part that cannot be deleted

Append-only is not a refusal to delete. Law, contract and ordinary decency all require that certain payloads can be removed, and a system that cannot honour a deletion request is not principled, it is unshippable.

The distinction is between the payload and the fact of the record. The payload may be tombstoned. That an entry existed, who produced it, and when, is retained — because erasing that does not protect anybody, it just makes the timeline lie. A tombstone says something was here and is gone. A gap says nothing was ever here, which is a different and false claim.

Two clocks, always

When the system recorded something and when it was true in the world are independent axes, and both are stored. A system with a single clock cannot answer what we knew and when we knew it — which is precisely the question asked in an incident review, a diligence process, or a regulator’s letter.

A worked example. A metric is recorded on the first of the month. On the twentieth you discover the instrument was misconfigured and the real figure was materially different from the first onward. With one clock you have two bad options: overwrite the original, which destroys the record of what the decision on the fifth was actually based on; or append a correction with today’s date, which implies the value only changed today.

With two clocks there is no dilemma. The correction is valid from the first and was recorded on the twentieth. Both are true, both are stored, and the question "what did we believe when we committed capital on the fifth" is answerable exactly. This is not an audit nicety. It is the difference between a portfolio that can learn from a bad decision and one that can only feel bad about it.

Provenance is a relation, not a decoration

Who produced an artifact, when, why, and from which inputs is a first-class edge in the graph, not a metadata field appended afterwards. The distinction is practical rather than aesthetic: an edge can be traversed, so you can ask what else depends on this input, or what conclusions rest on the instrument that turned out to be misconfigured. A metadata field can only be read once you already know which record to look at.

A claim without provenance is an orphan and is treated with suspicion however plausible it reads. This is the rule that catches the most in practice, because the confident unsourced assertion is the most common failure mode in both human and machine output.

Identity has to be stable first

None of the above works if entities cannot be referred to reliably. Identifiers are assigned at creation, globally unique, time-ordered, and never reused, never reassigned, never derived from a mutable property.

The derivation rule is the one that gets broken. Deriving an identifier from a name, a path, or a natural key is convenient and quietly fatal, because the moment that property changes the history splits in two: everything before the rename points at one entity, everything after at another, and no query will ever join them again. Identity has to survive moves, renames, and schema migrations, or the append-only log accumulates fragments rather than a history.

Is this over-engineering for a small company?

The reasonable objection is that this is a lot of machinery for an organisation that could fit its decisions in a document. The answer is that the cost profile is unusual: it is small, front-loaded, and cannot be retrofitted.

Choosing an append-only store with two clocks and provenance edges at the start costs a few days of design and approximately nothing thereafter — storage is cheap and the write path is barely more complex. Adding it later means reconstructing a history that was never recorded, which is not a migration, it is an archaeology project with a poor success rate.

The compounding payoff is unglamorous. A system that can show why it believes something is stronger than one that cannot, including in the case where both happen to be right — because only one of them can tell you which of its beliefs to revisit when the world changes.