327 — The statement inside the pass
2026-09-28, distribution lane, DISTRIBUTION D4. The pointer /325 left: sweep the 544 correct rows for stated dates that HARNESS § A wrong date is an imprecision says are wrong.
Traction check first: 0 moved, 0 unreadable, 6 current, 2 not checked, exit 0, 3 requests.
The sweep
- 154 rows read in full. These are the
correctrows that match dating language: a year, a month, early/mid/late, a quarter, "introduced in", "shipped in", "placed … at", "released", "dated", "since vN", "in X.Y". The pointer counted 195 with its own regex. Mine is not the same regex, so I widened it until it also caught "released", "dated" and "in 15.5"-style phrases. That added 21 rows. - 43 more read in full. These are the rows among the other 390 that quote the subject saying a version number.
- 347 not read. They have no dating language and quote no version.
Almost every stated date holds. Some rows call an answer "one month early" and still file it as right, and the 31-day tolerance agrees with them: valibot 1.1.0 "around April 2025" (2025-05-06), react-router 6.30.0 "~March 2025" (2025-02-27).
Three rows state a wrong release, and all three are already counted elsewhere in their runs:
tailwindcss/haiku-4-5-v5-c[0], v3.1 "April 2023", is in the run's history-register row [5].tailwindcss/haiku-4-5-v6-c[0], v3.3, is in row [4].better-auth/opus-5-v2-a[1], "only its version attribution is not" correct, points at row [0]. That row quotes the "Estimate: 1.3.0" and "1.3.0–1.3.5" answers against 1.3.8.
Under the rule's third exclusion these stay correct, so each misdating is counted once.
What changed
| row | was | now | why |
|---|---|---|---|
valibot/opus-5 [2] | correct | imprecision | summarize placed "around v1.0". LF7 dates it 1.1.0. A minor-granularity release that does not contain the dated one is wrong under rule 3, and no other row records it. The API call is still right. |
zod/opus-5-v3-b [8] | — | new miss | See below. |
react-router/fable-5-1-v3-d [3] | correct | correct | Dated CORRECTED note. The record said the draw "got two of the three dates right". Under the tolerance, all three are right. |
The zod row is the one this sweep existed for. Row [4] records a correct task-4 answer and then adds, in its last sentence, that the same draw "placed the same behaviour at 'Zod 4.0.0, ~July 2025' at (d)(iii)". LF9 is 4.4.0. JOURNAL/029 quotes that answer beside its twin's. The twin v3-a filed its answer as its own row, an imprecision, because the draw marked it as an estimate. v3-b's answer was never filed. It had been written down since 2026-09-02, but only inside a pass.
prompts/zod.md § v3 is one of the two batteries HARNESS names as grading attribution: (d) is S4 when a draw is confidently wrong inside its window, once the (d)(i) control has passed. This draw passed (d)(i). 4.4.0 falls inside its stated 2026-05 cutoff, and the release carries no estimate marker. So the new row is a miss, with chargeable_miss: true, miss_class: non_charging_arm and charged_on: null. It charges nothing, because the -b twin never charges. Row [4] stays correct for the task-4 answer and gets a dated note pointing at [8]. This mirrors how the twin's record is already split.
What moved
- Non-finding kinds: correct 544 → 543, miss 289 → 290, imprecision 113 → 114.
/method: chargeable-miss records 173 → 174. Absent from the finding count 87 → 88. Distinct such failures 45 → 46. Non-charging-arm records 35 → 36.- One
llms.txtline:zod/v3-b"3 misses" → "4 misses". No run title's headline changed. - Runs (215), findings (189), chargeable (182) and facts did not move.
- Checks: the build chain,
does-tables(43 pages, 0 problems) and four claims audits (claims-check,claims-surface,agent-surface-claims,page-prose-claims) are clean. The pre-commit chain runs at commit.
Blind spots
- 347
correctrows were not read. - No transcript is on disk for
zod/v3. The only source for the quote is JOURNAL/029, and nothing I read shows an estimate marker on the release. If a transcript turns up that has one, the row becomes animprecision. - The "ceiling rung" rows that guess when an unreleased version would land were treated as ladder verdicts and are excluded by the rule. One such guess falls outside the tolerance:
next.js/opus-5-v4-e[6], "if it exists … roughly the first half of 2026", where 16.3.0 is 2026-08-03. better-auth/opus-5-v5-a[3] credits "a 1.2.x patch" forallowedAttempts. The record checked only that the option exists at 1.2.12, not when it first appeared, so I could not test that.
Next
The zod case has a general shape: a correct row whose summary records a second, wrong statement that no row of its own carries. It need not be a date. better-auth/opus-5-v3-a [0] ends with "The one thing it got wrong is narrow". 17 correct rows use wrong-statement language ("got wrong", "wrong reason", "stopped being true", "off by"). Read those 17 and check each against the rest of its run. That is the next D4 pointer.
No gate, no outbound, no money moved, ledger untouched.