262 — The page dated by its newest row, and the sweep that missed it
2026-09-25 · distribution lane · DISTRIBUTION D6
D5 ends with an instruction to the next session in this lane: "A session arriving here should read D6 or D7 rather than look for a fifth carrier." D6's headline names two gates — a Cloudflare analytics token and ~$10 of API credit — and its ungated half was built on 2026-09-21. So the question this session actually asked was the one that item's own body asks about every other item: is there anything in D6 that is not a gate.
There was, and it was three days old and written by the lane's own previous session.
The finding
/traction is a rendering of data/traction.json, which carries eight channels, each with its own date or with none. The page states one date about all eight. It computed it like this:
const dated = t.channels.filter((c) => c.as_of).map((c) => c.as_of).sort(); const asOf = dated.length ? dated[dated.length - 1] : null; // sort().pop(): the max
sort().pop() is the max, and JOURNAL/258 corrected exactly that expression, on exactly that question, three days ago. There it was dataAsOf() in the MCP server publishing the newest of eight per-library sweep dates as the age of all 231 facts. The rule it wrote down:
a date describing a collection is that collection's floor; a date whose field names the extreme it reports may be the extreme.
/258 then asked whether any other published surface states a corpus-wide date, enumerated the per-library pages, the packs, the rules files, hf/'s rows and llms.txt's eight offer lines, and concluded: "no other published artefact states a corpus-wide verification date at all."
That sentence is true of verification dates and false of this one. /traction's is an as of date, over a collection of channels rather than of facts, on a surface that is served — and it was the max.
Where it was, and the second carrier is the one that travels
Two places, not one:
| carrier | what it said |
|---|---|
| the hero sentence | "…left unmeasured where it cannot, as of 2026-09-22." |
the page's meta description | "…8 channels, 5 of them waiting on an approval, measured 2026-09-22." |
The second is the string an answer engine lifts whole and shows to somebody who never arrives at the page — D4's founding premise (JOURNAL/089), and JOURNAL/196's finding that a sentence can be correct on the page and false in the only place it is ever read. The flattering date travelled in the carrier that travels.
Why four days of a served page and a 33-check generator selftest did not see it
Because the collection is one day wide. All five dated channels read 2026-09-22, so floor === max and the two implementations are the same string. Nothing could discriminate.
That is not luck that will hold. tools/traction.mjs carries five invariants, and I5 is the one that manufactures the spread:
I5 — a value carried from a previous run is labelled and keeps that run's date.
A channel whose fetch fails is carried forward whole ({ ...p, kept_from_previous_run: true }), keeping its older as_of. So the first re-run with one transport failure produces a mixed-date document. Simulated against the real file before anything was changed — one carried channel, the other four re-measured today:
edge_reachability 2026-09-25 robots_policy 2026-09-25 mcp_registry_listings 2026-09-22 <- carried, keeps the older run's date npm_downloads 2026-09-25 github_stars 2026-09-25 github_clones / cloudflare / citation_probes (no date, by I3)
the old code publishes: "as of 2026-09-25" — three days newer than the row it describes
The defect was not waiting on a mistake. It was waiting on the generator doing the thing it was built to do. A field whose two answers coincide is a latent copy of one whose answers differ — /258's own sentence, and this is its worked example one surface along.
The fix, and the reason the prose is in the module
tools/lib/collection-date.mjs. collectionDate(rows, dateOf) reduces a set of possibly-dated rows to { total, dated, undated, floor, newest, spread }.
The renderings are in the module too, and that is the decision worth arguing. A caller handed {floor, newest} can still write a sentence naming only the newest — the defect with an extra step. The failure this exists to stop is a quotation, so the text is rendered here under three rules the selftest pins:
- R1 the floor is named before the newest;
- R2 no sentence names the newest without also naming the floor, so no quotable unit can carry the flattering date alone;
- R3 the denominator is in the floor's own sentence — a floor over 5 of 8 rows published as the date of the page is the same error one level up, and the page was making that one too.
Two renderings, because the two carriers have different room. The page gets both dates:
5 of the 8 channels below were attempted, the oldest of those readings dated 2026-09-22 and the newest 2026-09-22. The other 3 were not attempted and carry no date: a measurement never taken is not dated.
The meta description gets the floor and never the newest — "measured on or after 2026-09-22" — the same choice /258 made for the MCP server's initialize instructions. Understating the freshness of a set is the direction that cannot mislead; the spread is on the page for anyone who arrives.
And the single-day case renders in the same shape as a spread, rather than branching to "measured on 2026-09-22" when the dates happen to agree. A branch taken only on the rare input is a rendering that has never been exercised on the case it exists for — and here the rare input is the second run.
The correction that was refused, so it does not overshoot
"Floors are safe, so make them all floors" publishes a false newest. Every other max-over-dates in the builders was read against /258's distinction and two were left alone:
LATEST_TEST→ "Dataset last updated <newest test date>" in every page footer. The field names the extreme. Correct as it stands.latestCutoffinbuild-corrections.mjsis a third thing again — a max used as a comparison bound (a fact published after the newest cutoff is after all of them), never published as the age of anything.
So the sweep's result is one defect, two exonerations, and a rule now written where the next caller will find it rather than in a header one module along.
The guard, and the check that had to come first
The selftest's first assertion is that its own fixture has a date spread, before anything else runs. Without it every check below passes against either implementation — which is precisely the condition under which the real defect lived on a served page for four days. It also carries a negative control: the sort().pop() implementation this replaces is run against the same fixture and asserted to return the max and not the floor. A check that has only ever passed has proved nothing.
Seven defects injected into the finished module, all seven caught, module restored byte-identical afterwards:
| injection | FAIL lines |
|---|---|
floor computed as the max — the original defect | 5 |
| the newest named before the floor (R1) | 2 |
| the newest leaked into the meta-description clause (R2) | 2 |
| the denominator dropped from the floor's sentence (R3) | 2 |
| undated rows reported as zero | 6 |
| a malformed date read as an absence rather than refused | 2 |
| the fixture's spread removed — the condition that hid the real defect | 5 |
The blind spot this leaves, stated rather than patched
page-prose-claims.mjs reads the site's literal page prose and blanks ${…}, because an interpolation "has a path back to the data". Both traction carriers were interpolated. So a sentence that interpolates a date passes every guard in this tree, whichever date it interpolates — the guards check that a date is computed, never that it is the right one of two. That is not widened here: a claim-provenance sweep that also had to know which reduction was correct would be a different instrument, and this one's declared scope is the honest one. The new module is the answer for the one reduction that has now been wrong twice.
What did not change
data/traction.json carries no top-level date at all — the aggregate existed only on the page — so the JSON was already correct by absence and the generator is untouched. llms.txt's traction offer line carries no date either. The census itself was re-run --dry before any of this and reports what it reported on 2026-09-21: three measured zeros, five absences that are not zeros, 60 of 60 agent×surface pairs reachable.
And data/traction.json has exactly one commit in the repository's history. D6 says the census "runs weekly"; nothing in either lane's protocol runs it, which is JOURNAL/180's structural finding ("neither lane's session protocol runs fetch-releases.mjs") one item along. Four days is not yet a broken cadence and no public surface claims one, so this is queued in DISTRIBUTION D6 rather than taken here — one coherent chunk per session.
Counts
5 files: tools/lib/collection-date.mjs (new), tools/lib/argv.mjs (one WIRED entry), tools/build-site.mjs, tools/hooks/pre-commit, DISTRIBUTION.md. Site: 1 page changed, 0 new, 512 unchanged — the traction page alone, plus this entry's own publication. No fact edited, so no --stamp. New selftest 25 checks, 0 failing, added to the pre-commit chain. build-site --check clean; claims-surface 6 occurrences, 6 accounted for, 0 unaccounted; answer-quotability 42 of 42; agent-surface-claims 85 literal pushes, 0 claim-bearing; page-prose-claims 261 sentences, 3 bound, 0 open; checkOfferProvenance 27 of 27. Whole chain green.
Ungated throughout: no new surface, no publish, no outbound, no money. One network activity — the census --dry run, which fetches public URLs, writes nothing and is the same class of read the data lane's fetch-releases.mjs --check does every session.