← All writing

The Forensic Fabric: how two people can both be right

Two people edited the same record and both think they are right. Most software answers that by picking a winner. The Forensic Fabric weaves both threads in — and keeps the seam visible.

Two people edited the same record. Both are certain they are right, and — this is the part that makes it hard — both usually are.

She updated the address on Tuesday afternoon from a plane with no signal. He updated the same address on Tuesday afternoon from the office. Neither knew the other was doing it. There is no lie here, no mistake, and nobody to blame. There are simply two true accounts of one Tuesday.

Almost every system you have ever used answers this by picking a winner. Last write wins. Or the server wins. Or a lock stops one of them from typing at all. However it is dressed up, the shape is the same: one version survives, the other is deleted, and no trace remains that there was ever a disagreement. For a shopping cart that is fine. For a medical record, a chain of evidence, a contract, or anything you may one day have to defend, it is a catastrophe wearing a green checkmark. The system is not merely wrong. It is confidently, silently, permanently wrong, and it has destroyed the only evidence that would have let you notice.

Your amber

Start with what you hold.

When you make something in this system — a record, a document, a finding — it is sealed into your amber. Amber is the right word for it because of what amber actually does: it takes something that happened, and it holds it exactly as it was, visible from every angle, without altering it. An insect in amber is not a copy of an insect. It is the insect, and the fact that you can see it at all is because nothing was rewritten to make it easier to store.

Your amber is yours in a way that most “your data” claims are not. Your keys are generated in your browser and never leave it. We do not hold them, and — this is the part that matters — we cannot. There is no vault of ours to breach, because there is nothing of yours in it. That is not a promise about our conduct; it is a property of the architecture, and you can watch it happen in your own browser’s developer tools.

Amber is the noun for your artifacts. The Forensic Fabric is the noun for the whole cloth. Your amber is a thread in it. The rest of this post is about how threads become cloth without anyone standing over the loom.

A commit is already a rollup. A branch is already a thread.

If you have used version control, you already know most of this and were not told it was remarkable.

A commit does not record “the file is now this.” It records this changed, from that, by this person, at this moment — and it names its parent. Follow the parents backwards and you have the whole history. That is a rollup: many small facts wound into one verifiable strand, where checking the strand checks everything inside it.

A branch is a thread that leaves the main weave and runs alongside it for a while. Nobody thinks a branch is a corruption. It is just work happening in more than one place, which is what work does.

And a merge — the part everyone dreads — is actually the honest bit. A merge keeps both parents. It does not decide who was really working on Tuesday. It records that two threads existed and that here is where they came back together. The history stays branched forever, because it was branched.

The Forensic Fabric takes that instinct — which programmers have relied on for decades and which nobody thought to extend to evidence — and applies it to the record itself.

Records that merge without a coordinator

Here is the property, stated plainly, because it sounds impossible until you have seen it:

Two people, each holding part of the record, working with no connection to each other and no server between them, can each merge what the other has — in either order, more than once, with pieces arriving out of sequence — and end up with the identical record and the identical proof over it.

No coordinator. No “who goes first.” No lock. Nobody has to be online, and nobody has to be trusted to be fair, because there is no privileged position from which to be unfair. Order of arrival stops being a fact about the truth and becomes a fact about the network.

This is not new mathematics. The family of structures that make it work is well studied and public: CRDTs — conflict-free replicated data types. The particular one the ledger is built on is the simplest and most stubborn of them, a grow-only set (a G-Set): you can add to it, you can never take away, and merging two of them is just set union. Union is commutative, associative and idempotent — which is the whole trick. Apply the two edits in either order, apply the same one twice, receive them out of sequence, and you land on the identical set every time, because union does not care. There is no “last writer,” because there is no writer that wins; there is only the union of everything anyone contributed.

What is unusual is applying that to a forensic record, where the thing being merged is not a shopping cart but a chain of evidence that has to survive someone attacking it later. And it is why, when two hands write the same ledger and it conflicts, the discipline is absolute: resolve by union, never by picking a side. Choosing “mine” or “theirs” produces a file that passes every check and has silently destroyed one hand’s work. Union adds; it never drops. You prove the result by set containment, never by comparing counts — a merge that added four hundred records and quietly dropped three hundred has a higher count and has lost evidence.

Because that changes the requirement. It is not enough for the merge to converge. The merged record has to remain provable: every thread still carries who made it, when, and under whose key; nothing is rewritten to make the arithmetic tidier; and the seams — the places where two histories were joined — remain visible as seams rather than being sanded flat.

So: she is right and he is right. Both edits are in the cloth. Both are attributable. The record shows a fork on Tuesday afternoon and shows exactly where it was rewoven. Anyone looking later can see there was a disagreement, see both sides of it, and see that nobody quietly deleted one.

A branch is not a break

The distinction the Fabric draws, and draws hard, is between a fork and a hole.

A fork is two threads. It is not damage. It is a completely ordinary consequence of more than one person doing work, and the correct response is to weave both in and say so.

A hole is different. A hole is where something should be and is not: a thread that arrives from nowhere, a reference to a record that no longer exists. That is not concurrency. That is missing evidence, and it is the thing you actually need to be told about.

Most systems get this exactly backwards. They panic at forks — throwing conflicts, demanding you pick a side — and they are serenely untroubled by holes, because a record with something removed is usually still perfectly self-consistent. It agrees with itself. It just no longer agrees with what happened.

The Fabric inverts that. Forks are structure and pass. Holes refuse.

A check that can refuse

Which brings us to the least fashionable idea here, and the one we would defend hardest.

A check that cannot fail is decoration. If a verifier returns green when it cannot see the thing it is supposed to be checking, it has not verified anything; it has performed verification. We have caught our own checks doing this, more than once, and it is always the same shape: the check ran, the check was happy, and the check was looking at nothing.

So there are three answers here, never two:

”Absent” and “fine” are different facts and are never merged into one green. A false alarm costs precisely what a false all-clear costs — you stop believing the instrument either way — so an instrument that goes quiet when it is blind is the worse of the two failures.

The discipline that follows from this is unglamorous and constant: watch a check fail before you trust it passing. A check that has never been seen to refuse has not been tested; it has been hoped at. Every verifier in this system has a deliberate broken input kept around to make it say no.

That is also why we would rather ship a record that says this one part cannot be proven, and here is why than one that is green everywhere. We have a live example we are keeping exactly as it is: a single entry written down long ago as a placeholder and never filled in, which every ordinary reader of the record accepts without complaint. It links. It sorts. It passes every check that treats it as just another identifier. Only the arithmetic refuses it — and so, downstream, one proof over that region declines to be computed at all.

We could make that go away in an afternoon. We are not going to. A green that was obtained by looking away is worth less than a refusal that names its reason, and a system that will not say “I cannot prove this part” cannot be believed when it says it can.

What it is for

If you never have to defend your records, none of this will matter to you and you should be glad.

If you might — because you are a journalist with sources, a clinician with charts, an investigator with an evidence set, a small firm with contracts, or simply someone who would like their own history to still be their own — then the properties are these, and they are plain:

The fabric metaphor is not decoration. Cloth is strong for a reason that has nothing to do with any single thread: it is strong because the threads cross, and because a cut is visible against the weave. Any one strand snaps easily. Woven, and with every crossing on the record, they hold — and when something is torn out, the hole has a shape.

The takeaway

Most software treats disagreement as an error to be resolved by deletion. That is a reasonable choice for a shopping cart and a catastrophe for a record you may have to defend. The Forensic Fabric makes the opposite choice, and pays for it with a discipline it never relaxes: add, never overwrite; prove containment, never counts; and let a check refuse when it cannot see. A grow-only set merged by union gives you convergence without a coordinator; append-only history gives you immutability; per-thread keys give you provenance. None of it is exotic. What is rare is the refusal to trade any of it away for a tidier green checkmark — and that refusal is the entire point.


The mechanisms behind these properties are described in gated technical writing; this post is deliberately about what the system guarantees and why it matters, not how it is built.

forensicsprovenancedata sovereigntyzero knowledge