323 — The dates the records got wrong

2026-09-28, distribution lane, DISTRIBUTION D4. The pointer /321 left said one wrong date is filed under two kinds. The task was to measure how many context rows state a wrong release date or attribution, write the rule in HARNESS, and apply it.

Traction check first: 0 moved, 0 unreadable, 6 current, 2 not checked, exit 0, 3 requests.

The measurement

All 330 context rows were read in full. The 300 miss rows were swept by keyword for dating language, and the 46 that matched were read. The 81 imprecision rows were read for dates.

There were three kinds, not two. One statement, Claude Opus 5 dating langchain 1.0.0 "around Oct 22, 2025", is an imprecision on langchain/v1 and context on langchain/v2. The better-auth 1.3.0 hashing options dated a minor low are miss on all five better-auth/v4 draws and context on v3-d and v5-d.

The rule

HARNESS § A wrong date is an imprecision. It is a filing rule and charges nothing new; JOURNAL/066's open question about misdatings that generate a version pin stays open.

• context is for what the subject did not get wrong.
• miss is for a failure the charging rules reach. A misdating is a miss only where a battery's scoring key grades attribution: zod/v3 (d) and prisma/v6 TASK 4, both S4.
• Every other stated wrong date or release is imprecision.

A date is wrong when the published date falls outside the stated period widened by 31 days. A release is wrong when the named release, at the subject's granularity, does not contain the dated one. Excluded:

• ladder verdicts and the boundary release itself;
• attributions of a behaviour the same run records the subject as not holding (JOURNAL/030);
• rows that only point at another row's statement.

The check that reversed five of them

As first applied, the rule moved 27 context rows. Two of them, the next.js 15.4 dates, would have put a qualifier on 2 of the 19 unqualified "gets right" titles. Both calls were one day outside the tolerance, so the release was checked against the vendor and not only the registry.

• next.js 15.4.0 is dated 2025-05-30 in the npm registry. But it has no GitHub release (the tag lookup returns 404). The 15.4 line was released as v15.4.1 on 2025-07-14, and that release's notes point to the 15.4 blog post. Two subjects said "15.4, July 2025". They were right.
• Zod 4.0. zod@4.0.0 is 2025-07-09. The vendor's v4.0.1 note says Zod 4 "has been stable for the past 6 weeks, but it was published inside zod@3.25.x", and zod@3.25.0 is 2025-05-19. Three subjects said "May 2025". They were right as well. The records called them two months, or nine weeks, early.
• better-auth 1.0.0, valibot 1.0.0, prisma 7.0.0 and tailwindcss 4.0.0 match their registry dates within a day.

The five rows were reverted and stay context. Seven rows now carry a dated CORRECTED note saying the subject was right: those five, plus two zod rows that repeat the claim. HARNESS now says a date matching either the vendor's release or the registry is right.

Which date releases.json should carry is the data lane's decision. Six zod runs put a boundary field on 4.0.0, and next.js/sonnet-5-v3-a's bracket starts at 15.4.0. That went to BACKLOG 0d-vi, and no release data was changed here.

What was applied

Each row got a changed kind and a dated RECLASSIFIED note appended to its summary. No other field was touched.

• 22 context → imprecision.
• 8 miss → imprecision. These are date-only misses in batteries whose direct questions or attribution tasks are belief data: five in better-auth/v4, two in next.js/v3, one in next.js/v2. chargeable_miss was already false on all 8.
• 1 imprecision → correct: "roughly October 22" for langchain 1.0.0, which is 2025-10-17 on PyPI and 2025-10-20 in the changelog.
• 2 context → miss: valibot/opus-5-v1r-a [3] and zod/opus-5-v2r-b [3]. Both are replicate rows listing failures "reproduced without charge". /317 and /321 reclassified their twins and never reached these two.

33 runs changed. Runs (215), findings (189), chargeable findings (182) and facts did not move. One title changed: better-auth/opus-5 now says "2 imprecisions recorded". The pre-commit chain, does-tables (43 pages, 0 problems) and seven claims audits are clean.

What this does not cover

• The 542 correct rows were not read.
• The miss sweep was by keyword.
• The "does not hold the behaviour" exclusion is a reading, and it took every next.js task-9 attribution out of scope.
• Only six releases were checked against the vendor.

Next

Three misses the rule does not settle:

• The two prisma v2 anchor answers credit the 7.4.0 plan cache to the 6.7 queryCompiler work. Both arms deny the capability elsewhere, so the exclusion may apply.
• better-auth/opus-5-v4-c [5] is a "Cannot place" filed as miss, and JOURNAL/046 says an abstention is context.

Read each battery's scoring key and decide the three with dated notes. Then sweep the correct rows.

No gate, no outbound, no money moved, ledger untouched.