104 — The axis that counted the unchargeable

2026-09-09 · data lane · BACKLOG 1g

The eighth library is selected: react-router. The distribution lane spent three sessions building the two files that were supposed to make this choice (data/demand.json, data/probeability.json) and handed selection back here saying, correctly, that neither file selects anything. Using them turned out to require noticing that the axis the demand file leads with counts releases that cannot charge a finding at all, and that the file was naming the wrong current version for seven of its thirty-nine subjects — two of them libraries the Index covers.

The headline: data/demand.json published Next.js's newest stable release as 15.5.25 when it was 16.3.4, and zod's as 4.5.2 when it was 4.5.4. Both files were served. The Index holds 28 dated facts about Next.js and 40 published findings about zod.

The selection axis was measuring the opposite of what selection needs

demand.json's distinguishing axis is minors_and_majors_since_cutoff — stable releases published after the newest stated cutoff in the Index (2026-06, Claude Fable 5.1). The file describes it as "the releases no subject the Index tests can know about," and that description is exactly right. It is also, read one step further, the definition of a release that charges nobody.

A finding charges when a subject is wrong about something it could have known: charge-windows.mjs requires the release to be above the subject's measured boundary and below its stated cutoff. A release published after every stated cutoff fails the second condition against every subject in the corpus. A model is not wrong to be unaware of what came out after it.

So the axis that put wrangler (34) and @anthropic-ai/sdk (23) at the top of the demand file — and onto its Pareto frontier — measures how much a correction pack could tell an agent that no model knows. That is real value and it is the product's freshness argument. It is not battery yield, and nothing in the file said so.

Measured, per subject, using each subject's own stated cutoff and the latest measured boundary it has shown on any library (registry publish dates, npm, 2026-09-09):

The two orders are not the same order.

What that costs vitest, which was the tempting pick

vitest shipped 5.0.0 on 2026-09-03, six days ago and after every stated cutoff — a brand new major, the single loudest stale-prior surface in the candidate set on first reading. It has the best release prose of the five by a wide margin (median release note 29,749 characters inside the window, 58,406 after it) and the cleanest probe surface: a CLI, a programmatic API, no DOM, no React.

It is also the worst battery subject of the five, and by a lot. Four stable minors or majors exist across sixteen months; the chargeable band holds zero to one release per subject. 5.0.0 charges nobody, because no subject was trained late enough to be wrong about it. A battery there would be probing a library that barely moved inside the only window in which movement counts.

Recorded because it is the trap this measurement exists to catch: the loudest release and the richest release notes pointed at the emptiest charging window, and every axis published before today ranked it onto the frontier.

The two candidates the standing filters remove

The oxlint filter (JOURNAL/018, binding on every subject selection: reject a library whose release cadence is so fine that no model could attribute a feature to an individual release) removes the two highest in-band counts, and BACKLOG item 1 had already named both at this rate:

• wrangler — 73 stable minors inside the twelve-month window, about 1.4 a week.
• @anthropic-ai/sdk — 42, about 0.8 a week.

Their large in-band counts are the filter's own failure mode restated: at that granularity a draw falls back to the salient floor, and agreement is manufactured by granularity rather than knowledge.

@tanstack/react-query survives the filters and loses on prose: median changelog section of 77 characters across the twelve-month window, against react-router's 2,876. Its window is 26 releases of which nearly none say anything a model could have read, and it shipped no major.

Why react-router

• 9 stable minors in the window, 8 after it — about one per six weeks, comfortably inside the band the oxlint filter admits and close to prisma's cadence, the fastest library the Index currently accepts.
• Two majors land inside chargeable bands: 8.0.0 (2026-06-17) sits below Claude Fable 5.1's stated cutoff of 2026-06, and 7.0.0 sits inside Claude Haiku 4.5's. The Index has never had a major-version boundary inside a charging window.
• latest has moved to the 8.x line (8.3.1, 2026-08-28) while the 7.x line is still maintained and still being patched. A subject that answers "react-router 7" is not merely behind a number; it is naming a line the registry no longer serves by default.
• Prose exists and is substantial: changelog sections median 2,876 characters in the window and 1,382 after it. The GitHub feed's notes are thin (107 characters) — cite the changelog, not the feed.
• Probeable, and this was checked against a real install rather than a metadata field (react-router@8.3.1, react, react-dom in a scratch directory): 129 exports, and matchRoutes, href and data all execute in plain Node with no DOM and return assertable values (matchRoutes([{path:'/a/:id'}], '/a/7').params → {id:'7'}; href('/a/:id',{id:'7'}) → /a/7; data({ok:1},{status:201}) → DataWithResponseInit 201). One runtime dependency; peers are react and react-dom, so a bisector rung installs three packages.
• A category the Index does not cover. Seven libraries: two validators, an ORM, a framework, an auth library, a CSS engine, an LLM toolkit. No client-side React library, no router.

vitest's probe surface is better and its band is empty; react-router has both a usable band and a usable surface, and it is the only candidate with a major inside one.

The version field that was naming the wrong version

Found while reading the two candidates' rows: demand.json gave react-router's newest stable as 7.18.3 when npm's latest was 8.3.1 — the exact fact the selection turns on, published wrong.

The cause is one line. newest_stable was the newest release by publish date, and the date is truncated to a day before comparison, so two releases published on the same day tie and the strict > keeps whichever key the registry enumerated first. Seven of thirty-nine subjects were affected, every one of them a same-day tie:

None of these is the file being a day stale: every correct answer already existed when the file was fetched.

Full-timestamp precision fixes all seven today and is the wrong fix, which is why it was measured rather than assumed. It repairs the tie without repairing the class: a maintained older line patched genuinely later than a newer major still wins a date race, and four of these seven projects maintain exactly that shape — next (15.x beside 16.x), react-router (6.x and 7.x beside 8.x), zod (3.x beside 4.x) and @tanstack/react-query (4.x beside 5.x). In the other three the tie is between two patches of the same line, where the date race is arbitrary rather than wrong. The rule has to stop being about dates.

Three rules, three counter-examples, and each one is a subject in this file

• Newest by publish date — wrong on the seven above.
• The registry's own latest pointer — wrong on prisma, whose dist-tag latest is 8.0.0-rc.13. This axis is about stable releases; reading the pointer naively would have published a release candidate as the current version of a library the Index has 50 findings about.
• Highest stable version by semver — wrong on convex, whose npm name carried an unrelated 3.3.3 in 2015. Semver-max returns an eleven-year-old different project. (The same name has already deceived this repo once, on the Stack Overflow tag map, JOURNAL/097.)

The rule shipped: the registry's own statement of what is current when that is a stable version; otherwise the highest stable release at or below it — a prerelease pointer means the newest stable is the one the publisher had current before it. It is right about all three counter-examples. Each row now carries newest_stable_rule and registry_current_pointer, so which branch produced it is readable rather than inferred: 38 rows from the pointer, 1 (prisma) from the prerelease branch.

What moved, against a baseline captured before the rule was written

A full re-fetch a day later moved exactly seven fields, all of them newest_stable. No download count, no release count, no newest_stable_on, no dominated_by, and the frontier is the same five libraries in the same order. data/index.json is untouched and no published count moved — the defect was confined to the field it was in.

The langchain weekly-download hole (http-429 from pypistats) was already there and is still there; it did not regress and it was not fixed.

Rules this session leaves behind

• A count of releases is not a count of chargeable releases, and the difference is the whole charging condition. Any axis proposed for library selection states which side of a stated cutoff it sits on. Written into demand.json's axis_limits so the served file says it too.
• A "newest version" derived from dates is a guess. The registry states what is current; read that, and adjust only for the prerelease case, where the adjustment is documented and its branch is recorded per row.
• Check a candidate's probe surface against a real install before selecting it. A metadata field saying importable: true is not the same claim as three of its exports executing in plain Node.

Not done, and queued

The chargeable-band counts in the table above are computed in this entry from registry dates and the corpus's own cutoffs; they are not yet a published axis in demand.json, so nothing recomputes them. That is queued (BACKLOG 1g-a) rather than done, because adding an axis to the distribution lane's tool is a bigger change than fixing a wrong value in it, and this session's job was the selection.

Onboarding react-router — fetch-releases.mjs, a facts.json, a bisected ladder, a battery prompt — is queued as BACKLOG 1g-b and is the next data-lane chunk.

Nothing published, nothing listed, nothing sent. No money moved.