100 — The field that was doing two jobs: a finding's version, decided and gated

2026-09-08, data lane (BACKLOG 11k-t-ii-i-f, and 11k-t-ii-i-g-f alongside it). The item was a decision the Index had been deferring: a finding's introduced_in and the fact it names are allowed to disagree, nothing checks them, and it is not obvious which number a finding should carry — the fact's measured boundary (what is true) or the release the run was tested against (what the battery did). The item said: decide it, write it into HARNESS.md, and only then sweep, over all seven libraries rather than the one that surfaced it.

The sweep ran first anyway, because a decision made without the count is a preference. It changed what this session was.

The repair half was already done, by a different item

The live drift the item named — the generator client { output } findings in prisma/fable-5 and prisma/sonnet-5, dated 7.0.0 against an LF4 re-dated to 6.6.0 — is gone. JOURNAL/096's citation sweep reached it two sessions ago through a different join and re-dated both to 6.6.0, without knowing it was closing this item's repair. So the whole-corpus sweep for the drift class returns, on the exact-api join, 114 joins and zero version mismatches — 117 counting the withdrawn rows, and zero date mismatches too.

That leaves a decision with nothing to fix, which is the best moment to make one and the best moment to build a gate: nothing has to be bent to fit, and the rule can be turned on the same day it is written.

The count that decides it

The two readings are not close. Across the corpus, 22 of 164 live dated findings sit outside the probe_window their own run drew — better-auth's 1.5.6 rows inside a battery drawn at [1.6.0, 1.7.3], zod's 4.3.2 rows inside one drawn at [4.2.0, 4.3.0], prisma's 6.6.0 rows inside one drawn at [6.18.0, 7.0.0]. Every one of the 22 is a bisector having moved a fact's boundary out from under the battery that charged on it. Under the run-reading, all 22 are wrong. Under the fact-reading, all 22 are right and the field has been correct all along.

Three readings settle it, and none is an argument about which is nicer:

  1. *The site renders the field as "changed in <library> <version>"*** (build-site.mjs, run pages and llms-full.txt). That is a claim about the library. The release a battery happened to install is not a claim about the library, and a reader has no way to know it was being told one.
  2. run.test.probe_window already carries the drawn window, on the run, which is the level a drawn window belongs to. Nothing was missing. The finding was being asked to carry the same thing twice, in a field that could only hold one of them.
  3. The corpus had already decided. Every bisect correction since JOURNAL/067 has been applied this way. The reading has been in force for a month with nobody writing it down — which is precisely why re-scoring two findings cost two backlog items and a day (JOURNAL/098): the rule existed only as a habit, and a habit cannot be checked.

Decided: a finding's introduced_in is the release at which the belief became wrong — the fact's measured boundary — and never the release its battery installed. In HARNESS.md.

The gate, and the two things it deliberately does not refuse

build-index.mjs now refuses a finding whose api resolves to exactly one fact carrying a different introduced_in, or the same release under a different introduced_on. The join is exact api equality, which JOURNAL/096 measured as the join that actually reaches records.

Two non-refusals, and both are structural rather than allowlisted — which matters, because an allowlist is a place to hide a case you have not understood:

Six mutations exercised in all. The one worth naming is the third: re-date a fact and leave its findings behind, which is the "reaches what charges and stops" class JOURNAL/096 had to find by hand across 447 comparisons. It is now caught by the build, in the same run, naming both rows.

What the decision breaks, said plainly

charge-windows.mjs keys its prior-charge column on this field. Under the decision, that column reports surfaces that are spent, not releases that have been drawn — and the two now visibly differ: prisma@6.6.0 names two charged subjects although no battery has ever drawn a 6.6.0 window. That entry is true under the surface reading (both were charged on LF4, whose boundary is 6.6.0) and false under the window reading.

The tool is not defective and was not "fixed". The temptation was to rewire it, and rewiring it would have been the mistake: the surface reading is the one a battery designer actually needs (which of this release's surfaces are already spent), and 11k-n's use of the column — quoting prior charges and then drawing anyway because that surface had never been charged — is already the surface reading in practice. What was wrong was that the column said already charged and named no object, so a later session could read it as "this release has been drawn". It now reads already charged on a belief dated here, in all three places it prints, with the reasoning in the source.

The honest gap this leaves: nothing in the repo answers "has this release been drawn against this subject". The material exists — run.test.probe_window, on every run but four — and is not in data/index.json, so the offline sweep cannot see it. Queued as 11k-t-ii-i-f-a rather than built, because it is a new index field and the current output is not wrong, only narrower than it sounded.

Alongside: the three prompts that pre-registered no severity (11k-t-ii-i-g-f)

prompts/prisma.md, prompts/zod.md and prompts/nextjs.md contained the string "severity" zero times. Each now states its position in its header block: no per-battery mapping, the HARNESS failure-mode scale binds, quoting all four levels in HARNESS's own words plus the correct-code-superseded case that is a non_finding at no severity — because a scale restated loosely in seven places is the drift this repo keeps generating for itself.

It is written as forward-binding and says so: effective for prisma/v6, zod/v7, next.js/v5, not retroactive, and it states why the paragraph exists — that its absence was indistinguishable from an oversight, and cost two backlog items and a day when nobody could tell without grepping whether a pre-registration existed to be violated. All seven battery prompts now state their severity position. The past findings were already scored under the HARNESS scale; none moves.

Counts

Nothing published moved, and that is checked rather than assumed: all five generated surfaces rebuild byte-identical apart from the files this session edited, and zero pages under site/ changed. 154 runs, 164 findings, 157 chargeable, 3 withdrawn, 7 facts files — every count as it was. A gate that changes a number on the day it is installed is a repair wearing a gate's clothes; this one is a rule the data already obeyed.

Chain green: 310 pages, 9,001 links, 5 surfaces, MCP 54/54, benchmark and flip selftests OK, citation sweep clean.

Found on the way, not fixed

The battery prompts carry the header "Published for method transparency" and are not a served surface — the site publishes prompts/benchmark.md and prompts/benchmark-bm1-draw.md and no battery spec. They are reachable only in the repository, which is private pending Sam's public-repo gate, and data/index.json names each run's battery_spec as a path a reader cannot open. The claim is not false — it is waiting on a gate — but it reads today as though those files are already public. Queued as 11k-t-ii-i-f-b: either serve them or date the promise.