On 2026-09-05 I grepped the file my own build writes its verdicts into. One line per control per commit, appended, never edited. $ grep COVERAGE DB/checks.generated.txt | tail -3 gate COVERAGE pass reason=OK_COVERAGE count=100/3849 tool=ddade5c8fb71 commit=ed6aafb gate COVERAGE pass reason=OK_COVERAGE count=100/3849 tool=ddade5c8fb71 commit=459b6f4 gate COVERAGE pass reason=OK_COVERAGE count=101/3850 tool=ddade5c8fb71 commit=53c8a17 Then the history behind those three lines: $ grep -c COVERAGE DB/checks.generated.txt 17 $ grep COVERAGE DB/checks.generated.txt | grep -c 'count=4/4' 14 Seventeen commits are recorded in that file. Fourteen of them carry count=4/4 and the word pass. Four is the number of subjects the coverage check reports on. Not four of four files covered. Four of four report rows emitted. The line was saying, in the column where the score goes, that it had counted itself and found itself complete. When the same check was pointed at the work instead of at its own output, the number came back 100 of 3849. The same file, two more shapes of the same problem $ grep -c 'count=0/0' DB/checks.generated.txt 148 $ grep 'count=0/0' DB/checks.generated.txt | grep -c ' pass ' 108 108 passing lines with nothing on either side of the slash. gate FIREWALL pass reason=OK_FIREWALL count=0/0 accounts for 11 of them, term FIREWALL for 6. A check over an empty set is true and says nothing, and my runner had no word for that: it folds an empty denominator into the same pass it uses for a real one. And the field itself has no unit: gate SWEEP pass reason=OK_SWEEP count=16451/0 membrane ONE_ROAD pass reason=OK_ONE_ROAD count=3/0 gate DOD pass reason=OK_DOD count=9/9 16451 samples with 0 failures. 3 writers with 0 bypasses. 9 of 9 rows. Same field name. Three meanings. The reader cannot tell which one is in front of it without opening the crate that printed it. 1193 of the 2271 lines in that file have a zero on the right of the slash, and I cannot tell you how many of those zeros are good news without reading each control. What I got wrong I looked at 4/4 for a day and read it as a score. It was in the score position, it was green, and I moved on. The arithmetic was never wrong; the number was simply about the instrument and it was sitting in the column where a number about the work belongs. Worse: the audit I ran over this project read every red line carefully and none of the green ones. Reds get attention because they demand action. A green with a wrong denominator asks for nothing, which is exactly why it survives. What I did not check Whether each of the 108 zero-denominator passes is a genuinely empty set or a dead reader. I know at least one of them was a dead reader, because I found it separately. The other 107 are unexamined and I am not going to pretend otherwise. I have not re-run the fourteen historical commits to see what a fixed check would have said at each one. The record is append-only, so the old lines stay as written; they are wrong and they stay. One project, one file, one person's controls. Nothing here says how common this is elsewhere. It says that a number in a green line is a claim like any other, and mine had not been read. The fix that is going in is small and it is not a better number: every control line carries the fields the device actually printed, and an empty denominator returns a third value instead of pass. count= is fixed to covered over denominator, so one name gets one unit. Trace: ledger DB/bands/decisions/01_DECISIONS.md, entries D-0046 (finding X2) and D-0048. The greps above were run on 2026-09-05 against DB/checks.generated.txt, 2271 lines. Repository: the rebuild these numbers come from is private while it is being cut. Its public predecessor is TraceFold/tracefold, and docs/LIMITS.md is where that project writes down what its own checks do not cover.