The bench that fooled itself

Not for confession, and not because bugs are interesting. This one is here because the shape of it is common and the catch was cheap, and because the alternative was worse than an ordinary wrong number. A bench that overstates a risk gets argued with. A bench that says a cheap precaution gives complete protection gets believed, acted on, and never revisited, because it told everyone what they wanted to hear about a control they had already installed.

The second reason is that the fault was not in the algorithm. The retraction code was correct. The lag code was correct. The reorganisation logic was correct. What was wrong was that one input drove two outputs, so a measurement of one of them was read as a measurement of the other. That failure has nothing to do with ledgers and will find you in any pipeline with a safety switch in it.

• Harness. The code that runs a thing and reports what happened. Distinct from the thing. Most of tonight is about the harness being wrong while the thing was right.
• Conflation. Two distinct mechanisms driven by one input, so no result can say which of them produced it. The fault tonight, in one word.
• Self test. Properties the engine checks on load. There are three, they all pass now, and all three also passed under the faulty code, which is the measurement this session turns on.
• Property. A statement that must hold for any correct run, checked rather than assumed. Stronger than an expected value, because it does not depend on a seed.
• Should-fail case. An input where a correct implementation is required to produce a bad outcome. The test nobody writes, and the only one that would have caught this.
• Determinism. The same seed gives the same answer. True of a correct bench and equally true of a broken one, which is why stability across seeds proved nothing here.
• Reorganisation depth. How many blocks deep a replacement goes. Bench B uses 3 unless the widget below is told otherwise. It is the thing the lag is being defended against.

Under the faulty wiring the wrong-row count went 511 at lag 0 and then 0, 0, 0 for every lag above it. Under the separated mechanisms it goes 511, 346, 172, 0. The two tables agree at lag 0, because at a lag of zero the faulty comparison is false and no retraction happens, and that agreement is part of what made the rest believable. The baseline was right, the sweep started from a real number, and then it fell off a cliff that was not there.

What a reader takes from the false table is a specific and dangerous lesson: set a lag, any lag, and you are covered. That is the opposite of session 7's conclusion, which is that a lag shallower than the depth is the worst configuration available because it buys partial protection at full freshness cost while removing the pressure to look again. A course built on the false table would have taught people to install exactly that and stop.

The 346 and the 172 did not go anywhere in the faulty run. They were deleted, and the run counted them as corrected rows, which is a field the engine returns and the published table did not show. The evidence was in the output the whole time, in a column nobody had a reason to read, because a single parameter had made the distinction between the two columns invisible.

The catch was not a feeling that the number looked odd. It was a specific statement that can be made before running anything: a defence that is shallower than the thing it defends against cannot be complete. A reorganisation replaces three blocks. A lag of one writes two of those three before the replacement arrives. Those rows are in the warehouse. For the wrong-row count to be zero, something must have taken them out, and a gate does not take anything out.

That is the reasoning worth copying, because it does not require knowing where the bug is or even that there is one. It starts from the mechanism, derives what the result has to look like, and compares. A result that contradicts the mechanism is either a discovery or a defect, and the prior on defect is very high.

Notice also what it is not. It is not "this seems too good", which is a mood and leads to a shrug. It is "this specific number cannot be zero, and here is the arithmetic". The first gets overruled in a review. The second ends the conversation.

One camp says the real lesson is about parameter design and nothing else. Two mechanisms behind one input is a design fault that no amount of testing reliably compensates for, because the tests are written by the person holding the same mental model that produced the conflation. Their prescription is structural: one input per decision, always, even when one of them is nearly always derivable from the other, and a review that rejects a boolean derived from a numeric threshold on sight. On this view the missing should-fail test is a symptom, and fixing symptoms is how you get a second bug of the same shape next quarter.

The other camp says that is unfalsifiable advice. Every parameter is derivable from something and every codebase has defaults; a rule against derived switches would reject half of the useful ergonomics in any library, and you would still be relying on somebody noticing which derivations are dangerous. Their prescription is behavioural: for every control you claim works, write the test where it should fail, and make the expected value non-zero. That test is cheap, it is mechanical, and it does not require anybody to have the right mental model, because it is derived from the mechanism rather than from the code.

Both are held by people who have shipped test suites that missed real defects. Notice that the evidence here splits them: the conflation was invisible in three passing properties, which supports the second camp, and the reason those three properties were the ones written at all is that the author's mental model had one dial in it, which supports the first. This bench now has both fixes, and no honest account of the episode says which one would have been sufficient alone.

Change the depth and watch the reported column. At depth 2, at depth 3 and at depth 4 it says the same thing: a real number at lag 0 and zero everywhere above it. The column the mechanisms were separated in moves a great deal, because it has to. At depth 4 a lag of 3 still leaves 170 wrong rows, and under the faulty wiring it reported zero, exactly as it did for depth 2.

A measurement that does not respond to the quantity it is supposed to be measuring is not a measurement. That is a stronger and much more usable diagnostic than "the number looks too good", because you can run it on a bench you did not write and do not understand. Vary the thing the control is defending against. If the reported protection does not change, the harness is not connected to the world in the way the label claims.

It is also the diagnostic that would have caught this without anyone knowing what retraction is. The false table's independence from the depth is visible from the outside, in the output, with no access to the wiring diagram in Part 1.

The faulty table was checked across four seeds before it was published, which felt like diligence at the time. Every one of them reported 0 wrong rows at a lag of 1. Under the separated mechanisms the same four seeds report 346, 337, 333 and 336, which is exactly the kind of small spread a real quantity has.

So the stability that was taken as evidence of correctness was evidence of determinism and nothing else. A seeded generator plus a deterministic bug gives the same answer every time, with the same confidence, and reproducing it four times reproduces the bug four times. Agreement across seeds tells you the pipeline is deterministic. It tells you nothing at all about whether it is right.

What would have been informative is the shape of the answers rather than their agreement. A quantity produced by counting real events has a distribution. An exact zero, repeated, is either a structural fact or a structural bug, and the way to tell them apart is to ask which structure makes it zero and check that the structure is really there.

The missing property is one sentence: against a reorganisation of depth 3, a finality lag of 1 with retraction off must leave more than zero wrong rows. On the harness's own configuration of 120 blocks it leaves 259, so the assertion can be written as a strict inequality and never needs updating when the generator changes.

Three things make that test different from the three that already existed. It has a non-zero expected value, so it cannot be satisfied by a mechanism that removes everything. It sits in the region where the control is supposed to be partially effective, which is the only region where partial and complete can be distinguished. And it is derived from the mechanism rather than from the implementation, so it would have been written the same way by somebody who had not read the code.

The generalisation is worth stating in the form you can apply on Monday. For every control you have claimed works, there exists a strength at which it must not work. Write that case down, assert the bad outcome, and make the assertion strict. A suite in which every expected value is zero or pass is a suite that cannot distinguish a working control from a control that has been wired to something that hides the evidence.

One honest caveat. This test would have caught this bug, and it is not a general proof of anything. A different conflation, wired to a parameter the suite never varies, would survive it. The habit that survives the caveat is the one in the closing band of the diagram above: look at the region between your obvious cases, because that is where the tests are not.