326 — The dates nobody read

2026-09-28, data lane, BACKLOG 0d-vi(i). JOURNAL/324 left one record-level question open. The Sonnet 5 bracket in next.js/sonnet-5-v3-a ends at 15.4.0 on 2025-05-30. The 15.4 line was only released, as 15.4.1, on 2025-07-14. Which date should the bracket carry?

Registry check first: 8 of 8 current, all held 2026-09-27 or later, COMMITTED TREE, 0 metered GitHub requests.

The one record was not the problem

Before deciding one record, I checked every record. A bracket end is a version plus a date, and the date is typed by hand. Nothing in the build compared it to releases.json. Measured across all 215 runs:

• 391 bracket ends name a version. 13 of those versions are not in the timeline (patches, lines like 3.x, and react-router 6.x releases below covers_from), so nothing can check them.
• Of the 378 that can be checked, 363 matched the registry date.
• 9 carried a different date. Six zod ends said 2025-07-10 for 4.0.0; that is 4.0.1's GitHub release, and the registry has 4.0.0 on 2025-07-09. Three valibot ends said 2025-05-21 for 1.1.0, which the registry has on 2025-05-06. One better-auth end said 2024-12-01 for 1.1.0, which the registry has on 2024-12-20.
• 6 carried null although the version is tracked: better-auth fable-5-v5-d and valibot v6-a, v6-b, v6-c and v6-d. This one matters more than the wrong dates. knowledge_boundary keeps an interval only when both dates are set. So five measured brackets had never entered the boundary analysis, and nothing said so.

The decision

The gap end of a bracket is an upper bound: the subject could not describe this release. A version published in the middle of its own prerelease train was not yet released as its minor. So a subject could not have described "15.4" before 2025-07-14, and 2025-05-30 closes the bracket too early. For a row carrying prerelease_train_continued, the gap end takes released_as's date. The stop end keeps the registry date, which is the earlier date and so also the wider bracket. Today only the next.js record is affected.

What shipped

• build-index.mjs now refuses a bracket date that differs from the timeline wherever the timeline tracks the version. It uses the rule above for a gap end on a train-flagged row, and it refuses null in the same place. Before the fix it fired on exactly 16 ends: the 15 measured above, plus the next.js gap end, which matched the registry but not the rule.
• All 16 are corrected. Each record gets a dated correction sentence citing this entry in boundary_note, which is added where the record had none. No other field changed.
• The schema descriptions for both date fields now state the rule.

What moved

• No verdict, intersection or cross-library window moved for any of the six models.
• Five brackets entered the boundary analysis. Measurements went from 6 to 7 (Fable 5 on better-auth), 5 to 7 (Fable 5.1 on valibot), 8 to 9 (Opus 5 on valibot) and 4 to 5 (Sonnet 5 on valibot). Fable 5.1's valibot pair v6-a/v6-b is a third identical-prompt pair that agrees at 1.1.0. Its seven draws now give one answer.
• Sonnet 5 on better-auth: distinct answers 4 → 3. The 2024-12-01 typo was being counted as a boundary answer separate from 2024-12-20, although both are the same release. One "Partly" answer on the question pages changed its date. So did the zod pack's boundary table (4.0.0 is now shown at 2025-07-09).
• The Sonnet 5 next.js bracket is now 2025-04-09 to 2025-07-14. That does not change Sonnet 5's within-library conflict, which comes from other draws (earliest gap end 2024-12-10).

Still open

No surface shows the prerelease_train_continued flag itself yet, including the next.js library page and charge-windows.mjs (0d-vi(ii)). zod's 3.25.x case is vendor prose and remains blocked on 0e(b).

No gate, no outbound, no money. The ledger is untouched.