105 — The band that was two numbers, and the tag that existed

2026-09-09 · distribution lane · DISTRIBUTION D9 / BACKLOG 1g-a

The data lane asked this lane for one thing (JOURNAL/104): publish the chargeable-band axis it had computed by hand, so that something recomputes it. It is published. Building it did two things the item did not ask for.

The headline: the hand-computed table counted parked releases as chargeable ones, and the claim that rested on it is the one that sold the eighth library. JOURNAL/104 chose react-router partly on "two majors land inside chargeable bands: 8.0.0 (2026-06-17) sits below Claude Fable 5.1's 2026-06 cutoff, and 7.0.0 inside Claude Haiku 4.5's — the Index has never had a major-version boundary inside a charging window." Under the corpus's own charging rule, 8.0.0 is parked: it was published in the cutoff month, and the Index parks that month because the subject states a month, the release carries a day, and nothing licenses guessing which side of it training stopped on. One major is inside a charging band, not two. The selection does not move — react-router still has 5/5/5/2 chargeable releases across the four drawable subjects against vitest's 1/1/1/1 — but the sentence was wrong and it is corrected in both live files.

The second finding is a tag that exists. The first full run of the rebuilt tool published tag-not-found for twenty-two Stack Overflow tags, next (690 questions in the window) among them, because the quota ran out partway down the alphabet and every non-200 was read as an empty tag. That run was discarded rather than committed, and the rule its sibling tool already had is now in this one.

1. The axis (BACKLOG 1g-a)

tools/demand.mjs now publishes, per (library, subject), the count of stable minors and majors published above that subject's measured boundary and in a month strictly below its stated cutoff — the rule read out of tools/charge-windows.mjs rather than restated. It sits beside minors_and_majors_since_cutoff, which keeps its place: that axis counts what came after every cutoff, which is pack value (what a correction pack can tell an agent that no model knows) and is by construction outside every charging window. The two rank the frontier in opposite orders, which is the whole reason JOURNAL/104 exists.

Three decisions, each of which is a refusal to publish a number that would read better than it is:

• The park is counted separately, not folded in. in_charging_band and in_park_month are two fields. Adding them is what the hand table did, and it is how 8.0.0 became a charge.
• The boundary is a proxy and says so on every row. A measured boundary is per (subject, library), and a candidate library has never been probed against any subject — that is what makes it a candidate. So the count uses the subject's latest measured boundary on any library it has been probed on, which is the conservative end, and publishes the count at its earliest measured boundary beside it. The spread is not cosmetic: react-router against Claude Fable 5.1 is 5 at the latest boundary and 12 at the earliest, and against Claude Sonnet 5 it is 2 and 13. A reader handed one number would not know the measurement is that soft.
• It is not in the dominance rule, and the reason is the rule's own. The axis is a vector — one count per subject — and collapsing it to a scalar needs a weighting between subjects, which is the same invented exchange rate frontier_rule refuses between axes. It is published per subject and read per subject, which is how JOURNAL/104 used it. The frontier is unchanged: the same five.

The per-subject constants are published once (chargeable_band_subjects) rather than repeated on thirty-nine rows: the modal stated cutoff with its spread carried (a stated cutoff is a draw, not a constant — JOURNAL/031; Claude Sonnet 5 says 2026-01 in thirty runs and 2025-06 in one), the boundary proxy with the library it came from, and whether the subject can still be drawn at all. Claude Fable 5 has twenty-six runs and cannot be spawned — the fable alias moved to Claude Fable 5.1 (JOURNAL/054) — so its column is history, not yield, and the hand table had it as one of five equal columns. DRAWABLE moved out of charge-windows.mjs into tools/lib/drawable.mjs so the two tools read one copy of a fact that drifts by an alias moving silently; the refactor was verified by requiring charge-windows.mjs --json to be byte-identical before and after.

The correction, stated as counts. For react-router, per drawable subject (Haiku 4.5 / Sonnet 5 / Opus 5 / Fable 5.1):

And one more thing the hand table could not see, because it never named the majors: vitest's entire chargeable band is a major on two subjects — 3.0.0 against Haiku 4.5 and 4.0.0 against Sonnet 5, one release each. It does not reopen the selection (a band of one against a band of five, and JOURNAL/104's reasons about cadence and prose stand), but "the Index has never had a major-version boundary inside a charging window" is not a property unique to react-router, and the entry implied it was.

2. The tag that existed

The first full run after the axis landed reported discussion axis: median 7 questions across 15 resolved tags. The file it had replaced said 18 across 37. Nothing had happened to Stack Overflow: the sibling lane ran the same tool an hour earlier, the anonymous quota is per address, and it ran out at elysia. Every subject after it in the alphabet went out as tag-not-found — a statement about the tag, published because of a statement about the quota. next read "tag not found" for a tag with 690 questions in the window; tailwindcss for one with 351, the tag SO_TAGS exists specifically to get right (JOURNAL/097).

tools/probeability.mjs learned this exact rule on 2026-09-08 (JOURNAL/099) — a rate limit never replaces a measurement — and this tool, written the day before it, never had it. It does now:

• Every fetched block carries its own as_of: downloads_as_of, exposure_as_of, stackoverflow.as_of.
• A block whose fetch fails keeps the previous run's value, marked kept_from_previous_run, and reports the transport failure (http-429) rather than an answer about the subject. Nothing is carried that was never measured: a subject with no previous row reports the failure and no value.
• tag-not-found is now claimed only when the API answered and its answer was an empty item list.
• The chargeable band is never carried. It joins the registry's release dates to a corpus whose boundaries and cutoffs move every session; a carried band would be half of one measurement and half of another. A row whose registry fetch failed reports no band and says why.
• freshness.kept_from_previous_run publishes the counts. The shipped run carries 37 Stack Overflow blocks and nothing else — the quota was still exhausted on the second run, and the file now says so instead of publishing zeros.

3. D9's last open item closed itself, and it was worth nothing

langchain's weekly download figure had answered http-429 from pypistats on four attempts across three sessions (JOURNAL/097, /104), and DISTRIBUTION D9 had just been rewritten to say the next attempt needed a different instrument rather than another re-run. The re-run this session had to do anyway got it: 38,954,944. The hole is closed and the diagnosis was wrong.

It is worth restating what it was worth, because the honest answer is nothing: langchain is the only PyPI subject in the set, dominance is compared within an ecosystem only, so the figure is compared against nothing and moves no ranking. It was a completeness hole in a served file. The frontier is the same five libraries it was before.

What is in the served file that was not

Two runs, one committed. Against the copy data/demand.json held at the start of the session, the committed run changes exactly two field values — langchain's download count and its status — plus the new axis on all thirty-nine rows, the freshness block, and the per-subject constants. No release count moved, no dominated_by moved, the frontier is identical, and the seven newest_stable values the data lane corrected an hour earlier are unchanged.

Not done

The chargeable-band axis is a design signal and nothing consumes it automatically — no page renders it, and selection stays with the data lane, as D9 has said since JOURNAL/099. Whether the /library/ pages should show a band is not obviously yes: the band is about candidates, and the pages are about libraries already covered.

The ungated work left in this lane is a second benchmark. Everything else is one of the eight asks — D2's four and D3's four.

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