Two of my checks print a field that says how much of the world they looked at. Here they are, run on 2026-09-05: $ node tools/cells.mjs --check 1 FAIL_CELLS count=276/276 unassigned=0 twice=0 orphan_attachment=0 stale=1 $ node tools/layer_index.mjs --check 1 FAIL_LAYER_INDEX md=DRIFT html=DRIFT unmapped=0 code=53c8a17 twin=53c8a17 fresh=1 twin_scope=code chain=11 unassigned=0 is the load-bearing word in the first line. It means every file in the tree landed in exactly one partition and none were left over. twice=0 means none landed in two. chain=11 in the second line means the layer order came out of the dependency graph rather than out of my head. Now the file those runs are supposed to be recorded in: $ grep -c 'unassigned=' DB/checks.generated.txt 0 $ grep -c 'twice=' DB/checks.generated.txt 0 $ grep -c 'chain=' DB/checks.generated.txt 0 $ wc -l < DB/checks.generated.txt 2271 Zero, zero and zero, across 2271 recorded lines. The words exist in the tools and they do not exist in the record. Where they go The runner does not read a verdict out of a control line itself. It hands the line to a binary that parses it, and takes back a normalised form: const words = line.split(/\s+/); read.push({ name: words[1], verdict: words[2], text: line, raw }); Name and verdict. Everything after position two survives only in whatever the parser chose to re-emit, which is reason= and a single count=a/b. The device's own vocabulary stops at the door. Why that emptied a whole ledger I had written a rigor ladder for comparing this project against the older ones it is meant to replace. The rungs are ordinary: a claim is declared, or range-checked, or domain-measured, or well-defined. The rule attached to it is the part I still believe in: a rung is reached by a print, not by an argument. If you say you measured the whole domain, the totality figure has to be in the record. The totality figures were not in the record. So when the ledger was re-scored against its own rule, almost every row capped one rung below where I had put it. Measured by that pass over 321 comparison rows: rows I had marked as ahead fell from 38 to 11. Six of the surviving 11 are on a check that reports what the project has not measured, which is an honest thing to publish and a thin thing to win on. On the product axis proper, ahead was 0. What I got wrong I wrote the ladder in one stretch and the recording format in another, and I never asked the one question that connects them: does the evidence this rule demands survive the trip from the tool to the ledger? It is a boring class of bug and it does not look like a bug from either end. The tool prints the right thing. The record is well formed. Only the join is broken, and nothing was watching the join, because I built both sides and assumed the middle. There is a second-order version of it I like less. When the re-scored numbers came in, my first instinct was that the re-score was too harsh. The rule was mine, written down before the result, and I still wanted to argue with it once it cost me something. What I did not check Whether the missing fields would have changed any individual verdict if they had arrived. Some rows would have stayed exactly where they were. I have not gone row by row, and the honest tally today is the low one. The record covers 17 distinct commits. The repository has 80. Everything before the runner existed is unmeasured and will stay that way, since the file is append-only by design. I also have no evidence that any of this generalises. It is one build, one runner, one person who wrote both ends of a pipe and never watched what came out the far side. Trace: ledger DB/bands/decisions/01_DECISIONS.md entry D-0048, and the runner code quoted above at tools/run_checks.mjs:213-215. The greps and both --check runs are from 2026-09-05. Repository: this rebuild is private while it is being cut. Its public predecessor is TraceFold/tracefold, where tools/e2e.sh is the script whose exit status is supposed to mean something.