102 — The column that answered the other question

2026-09-08 · data lane · BACKLOG 11k-t-ii-i-f-a, 11k-t-ii-i-f-b

JOURNAL/100 decided that a finding's introduced_in is the fact's measured boundary and never the release its battery installed. That decision was right and it broke something honestly: it turned charge-windows.mjs's prior-work column into a statement about surfaces that are spent, not releases that have been drawn. The column was relabelled in all three places it prints and the second question was left with no answer anywhere. This session builds the answer.

The headline: prisma@6.6.0 is the only release in the corpus that is charged and was never drawn. JOURNAL/100 named it as the case that proved the two readings differ. It is now measured rather than argued, and it is the whole of the release-level divergence: 32 releases carry a charge, 31 of them were also drawn.

The two columns, and the count that says they are worth having separately

run.test.probe_window was on 150 of 154 runs and in no derived surface, because charge-windows.mjs reads data/index.json and nothing else. It is now carried into the run projection — 604 added lines, zero deletions, no published number moved — and the sweep prints drawn beside charged, as a second column and not a replacement. The item was explicit about that and it was right to be: the surface reading is the one 11k-n actually used (quote the prior charges, then draw anyway because that surface was virgin), and swapping one for the other loses a question that has been answered correctly all along.

Of 184 (release, subject) cells carrying at least one mark:

The 122 is the number that justifies the second column. A drawn window that came back empty for a subject is the common case — a battery works in a range and charges some subjects and not others — and nothing in the repo could see it before. Per subject: Opus 5 32, Sonnet 5 27, Fable 5.1 24, Fable 5 21, Haiku 4.5 18.

The 9 is the divergence the item was opened for, and four of them are unverified rather than confirmed (they sit on zod releases, below). The five confirmed: prisma@6.6.0 × Fable 5 and Sonnet 5, prisma@6.8.0 × Fable 5, prisma@7.1.0 × Fable 5.1 and Sonnet 5. Every one is a bisector having moved a fact's boundary out from under the battery that charged on it — the class JOURNAL/100 measured at 22 of 164 findings, seen here from the release side.

Unrecorded is not empty

Four runs carry probe_window: null: zod/v1's four original arms, one per subject, which predate the field. That is not "these batteries drew nothing" — it is "the corpus does not say what they drew", and the difference falls entirely on zod, where every subject's absence from the drawn column is unverified. The tool prints those as [?subject] on the five affected releases and names the four runs in its JSON output under runs_without_a_recorded_window. Four of the nine charged-not-drawn cells sit exactly there, which is why the confirmed count is five and not nine.

This is the same rule the distribution lane arrived at twice this week from the other side — a rate limit never replaces a measurement (JOURNAL/099), a changelog covering the wrong period is unmeasured rather than empty (JOURNAL/099). A missing input is a third state, never the negative one.

The defect, found by reading the output rather than the code

The first working version printed, on the zod 4.2.0 and 4.3.0 rows, that Claude Haiku 4.5 had drawn the release and that its drawn-status was unverified. Both marks, same row, same subject.

The cause is an identity mismatch between the two columns' sources: index.findings carries the model's label, index.runs carries its model_id, and the corpus carries one subject under two ids — claude-haiku-4-5 (9 runs) and claude-haiku-4-5-20251001 (1 run, the dated id). Printing both columns as labels merges them correctly; comparing them as ids did not. Every cross-column comparison is now on the label, and the note explaining why sits at the top of the file rather than in this diff. The bug was visible only because the unverified marker prints beside the drawn list on the same line — the same property that caught JOURNAL/101's regex defect (a count that was true beside a name that was a lie).

Found on the way and fixed: DRAWABLE's Fable 5.1 note said "10 runs" and the tool prints a live count on the line above it; the number had been 24 for some time. Hand-typed counts beside computed ones are a standing hazard in this repo and the fix is to stop typing them.

Verification

The drawn map was rebuilt from the raw run files rather than from index.json — a different source and a separately written loop — and compared across all 64 releases: 0 mismatches. Version comparison is numeric rather than lexical, which is load-bearing: probe windows name patch releases (1.4.2, 1.7.2, 1.7.3, 16.0.3, 4.4.3) and 1.10.0 sorts below 1.9.0 as a string. data/index.json gained one field and lost nothing; the pre-commit chain is green on all five generated surfaces, the MCP server, the benchmark runner and the flip test.

The second item: a promise that was true about intent and false about today

All seven battery prompts carried the line "Published for method transparency." They are not published. The repo is private pending Sam's public-repo gate (BACKLOG item 3), prompts/ is CC BY 4.0 under LICENSING.md and goes public with it, and the site serves exactly two prompt files — benchmark.md and benchmark-bm1-draw.md — neither of them a battery spec.

The claim is not a lie about the future and it reads as a claim about the present. The fix taken is the item's own preferred one: date the promise rather than keep it or drop it. Serving the battery specs was refused on its merits — it publishes the exact wording of batteries that have not run, which is a real methodological cost, and it is a surface change and therefore Sam's gate anyway.

Checked rather than assumed: the site's own rendering of battery_spec already reads "prompts/prisma.md in the studio repo", which claims no reachability. The overclaim was confined to the seven prompt headers, and one edit closes it. No generated surface moved.

Nothing published, nothing sent

The repo is still private, the MCP server is still unlisted and unpublished, and Sam's outstanding asks are unchanged (DISTRIBUTION D2's four and D3's four).