SociumA design document declared a closed union over three authorities. The requirements restatement written from it described one. The spec kept the phrase “closed canonical union” as prose and never typed the field. The invariant covering the area described a different projection. All three acceptance criteria could be satisfied by an implementation handling a single variant, and neither mapped verification entry could fail on a missing member.
The implementation delivered one variant and returned a hard error for the rest. History reads failed on any session with a completed interaction.
Every check passed. The implementation was correct: it did what the spec told it to do, and the spec was not what the design declared.
What was missing
Evidence handling has a name for this. A chain of custody records every transfer of a thing between hands, so that what arrives can be shown to be what left. Break the chain and the evidence is worthless even when nothing was tampered with, because nobody can say it is the same evidence.
A requirement changes hands at least five times before anything runs. Declared in a design. Restated in a requirements document. Formalized in a spec. Covered by an invariant. Expressed as acceptance criteria, then realized in code and tests. Nothing in that sequence recorded what it received or checked it against what was sent.
The union was declared once and never again. Each artifact after the first was faithful to its immediate predecessor, and each one was correct on its own terms. The requirement was not tampered with. It was dropped, at a transfer nobody was watching, and everything downstream then did honest work on the wrong thing.
That is the whole defect. It is not a story about carelessness, and no amount of reading the documents harder would have surfaced it. It surfaced because of how the audit was asked for. The question was not whether the documents were correct. It was where the requirement had been dropped or mutated, which points at the transfers rather than at the documents.
Why it breaks here
A human chain has an accidental check built into it. Different people write the design, the requirements, and the spec, and the differences between them surface as questions. Someone reads a restatement, does not recognize their own requirement in it, and asks.
One producer writing every hop removes that. The design, the requirement, the spec, and the tests come from the same source, so a check derived from the spec inherits whatever the spec dropped. The verification and the work share an origin, and the check confirms the producer’s account instead of testing it. Nothing disagrees with anything, because there is only one account.
This is why the boundaries have to be deliberate now. They used to come free, as a side effect of the work being divided among people who could not read each other’s minds. The general form of that argument, that reliability is a property of the channel around the model rather than of the model, is in the paper.
Where the boundaries go
Three of them, because the transfers differ in kind.
The first is where an open intention becomes a closed list of what the work has to do. Deciding what is in and what is out is the whole job, and no machine does it, because that is where judgment about what to build lives.
The second is where each item on that list becomes a predicate that decides it, plus a statement of what would make that predicate fail.
The third is where the thing gets built and measured against those predicates.
Run the first two together and the same pass that drew the boundary is the one that writes it up, so nothing outside that pass can check the write-up kept it. Run the last two together and the producer sets the predicates it will be judged by, which is self-verification with extra steps. The separations exist so that each transfer can be checked by something that did not perform it.
Which means the checks read two artifacts at once and compare them. A per-artifact review, at any level of rigor, finds nothing, because the defect is not in any artifact. And coverage is measured against what the design declared, never against the spec’s retelling of it. Key a check to the restatement and it will faithfully confirm the narrowing.
What this does not do
It carries fidelity, not sufficiency, and that is the boundary rather than one caveat among several. Custody keeps what was declared intact through every transfer. It says nothing about whether the right things were declared. A design that closes the wrong set, carried perfectly through every hop, produces confidently wrong software and passes every check.
That part rests on human judgment. Structure helps, since deriving the list from the architecture makes “did we cover every boundary, every use case, every adapter” something you can check rather than recall. It does not solve it. Whether a list covers what someone actually meant is not a question anything here can answer, and the human is left facing the same problem the system exists to defeat, that an absence leaves no trace, moved one document upstream.
Worth saying plainly, since it is the part that surprised me: being correct at every point does not make the whole thing correct. A chain of individually correct documents can fail to preserve the thing they were collectively about.