Write the third implementation¶

The two implementations produced 13 and 9 open items. Four of them are the same item. That is 18 distinct findings and an overlap of 22 %.

Overlap that low is measurable information about what is left. Capture–recapture puts the findable population at 27–29 items, so roughly ten holes are still unfound — and that is a floor, not an estimate of the worst case: shared blind spots fall outside the population entirely, and gaps obvious enough for everyone to find inflate the overlap. Both biases point the same way.

Pin what works by accident — then make the pin fail. An implementation does things correctly for reasons nobody chose: a prefix on a name, a predicate reused from elsewhere, a container picked for an unrelated reason. Such an accident is not merely unargued but fragile — it holds until some unrelated tidying walks past it. The right treatment is not to justify it afterwards but to pin it with a test: a justification ages with the reader, a test does not.

But the pin is itself a claim, and a claim must be tested. In this project two such accidents were pinned and then broken one at a time in a copy. One pin held. The other did not: the change passed all 209 tests unnoticed, because the implementation had two independent guards and only the first did any work — the second was a spare part. No amount of reading would have shown it. Two overlapping protections hide which one works, and the only way to find out is to remove one.

A pin never seen to fail therefore does not demonstrate fragility; it demonstrates belief in it — and a convincingly written wrong pin is worse than no pin, because it looks like work already done.

Publish what you send, not only what you accept. An implementation's acceptance surface can be listed by a tool: every message, every field missing and mistyped. That is half. The other half is the emission surface — every message the implementation actually sends, produced by running its own code rather than by writing examples by hand. A hand-written example states what an implementation is assumed to send, and that assumption is precisely what was wrong in item H55.

When two implementations publish their emission surfaces, each can run the other's against its own acceptance surface. That finds severing incompatibilities with no network, no permissions, and neither side changing a line — and it does not replace a real cross-run, which measures order, timing and state; it empties the class of fault that would stop such a run in its first second. This project's first severing incompatibility was found because one implementer mentioned their identifier format in passing in conversation. That is a poor way to find them.

Three faults, three ways of finding them. Between 19 and 21 September 2026 three faults were found in production code. The first turned up while an implementer was looking in the wrong file for something else. The second came from a listing that walks the whole acceptance surface and asks nobody what is worth testing. The third came from a question neither implementer would have thought to ask itself. Only one of the three would have been caught by a test written in advance — which is the same reason this page asks for a third implementation rather than a third review pass.

Measured afterwards. That was computed on 13 September 2026. Since then eleven more items have been numbered (H36–H46) — seven of them on one day, 19 September, by asking both implementations the same questions of their code and comparing the answers. "Roughly ten unfound" was met in six days without a third implementation, and the floor was a floor: nothing says the population is now empty.

An implementer finds the gaps that their own structure runs into. One implementation sends loads to a joining client, so its author hit the joining message order; the other does not send them, so its author never did. This is why the useful variable is the number of implementations, not the number of review passes — and why the most valuable thing anyone can do with this specification is implement it a third time.

The more different the structure, the more it finds. Preferably one without arbitrary-precision integers, because that hits N12 and N14 from a direction neither existing implementation can.

What predicts divergence¶

This is the most important finding of the exercise, and it runs against intuition.

Divergence is not predicted by the size of the consequence. It is predicted by the number of natural readings.

Two measured cases point in opposite directions:

For H25 the consequence would have been wide, but an integer is so nearly the only natural reading that two implementers hit it without consulting each other. For H30 the fix is one string long, but "protocol generation" and "document version" are both equally natural readings — and the cross-run stopped at the first message.

Which gives the third implementer a practical rule: when you meet a field, ask what its legal values are — not only what its type is and what follows from a mismatch. That is exactly the question nobody asked about H30. The specification answered the type and the consequence, and no one noticed that the value was still unsaid.

The test that could not have failed¶

This project has run into one shape of mistake four times, in four different places, and each time it looked like a different fault. It is worth learning the name before writing a single test: the instrument was right about what it measured, it just did not measure what anyone thought.

The first three are measured figures. The fourth was on this site, and an implementer found it, not a review.

A practical rule for the third implementer: a passing test tells you nothing unless it could have failed. Write down, for every test, the wrong answer it is supposed to reject — if you cannot write that, the test discriminates nothing. It is the same requirement N5 places on test vectors, and it holds for examples just as well: an example that succeeds only because it avoids the hard case is more dangerous than a missing example.

When to stop¶

The stopping rule is not the number of findings but the overlap. When a new implementation finds mostly items that are already known, the population is running out.

22 % is nowhere near that. As long as the overlap is low, the cheapest next move is another implementation rather than another review pass.

Cite the versioned clause, not the clause: "§2 / commontime/1", never "§2". The specification is under the same version control as the tests that check it.