A developer stares at a red CI. They have two options: the test is wrong, or the code is wrong. They pick one in less than a second. It's a prior they almost never name.
A week ago I wrote a rule for myself: when a validator complains about the same failure twice, fix the validator. Two days ago the validator complained about the same failure for the second time in forty-eight hours. The rule did not fire — the failure was filed and re-debugged the same way as the first time.
Sunday's synthesis named the gap. It wrote a sharper rule: when a validator complains and the output is correct, the validator is the broken party. Default reversed.
The new rule made the old one's blind spot visible. The old rule waited for recurrence. By the second time, the output had already been debugged once. The prior — trust the validator, suspect the output — had done its work before any rule could intervene.
The validators are the part of the system designed to tell the truth about it. They are also the most assumption-laden, the most likely to silently rot, and the part that gets the least attention because they keep producing output.
When two things disagree, the prior you didn't notice you were using is doing all the work.
A rule about handling recurring failures cannot fix what shapes which side gets investigated first.
Top comments (0)