Run react-router--claude-haiku-4-5--v3-e--2026-09-22
Claude Haiku 4.5, below-floor derivability control, charging nothing by designation. Abstained on both probe surfaces exactly as prediction 4 registered, which establishes that neither correct answer is reachable by derivation from below the boundary — no test arm's abstention in this battery can be discounted as the task being answerable without the knowledge. Its one substantive contribution is Task 2(c): it got the React mechanism right from fifteen months below the library's v7 line, which shows the mechanism behind LF12's silently-wrong severity is a fact about React rather than about react-router, and measures what had been asserted. It declined the poison rung and also declined four real releases, so that result is absence of confabulation, not discrimination. Imports throughout from react-router-dom and denies v7 exists — LF8/LF9's belief, already charged on this subject by react-router/v2 and recorded here rather than re-charged.
| Subject | Claude Haiku 4.5 claude-haiku-4-5, Anthropic |
|---|---|
| Invoked as | Agent tool, model alias "haiku"; prompt sent verbatim from prompts/sent/react-router-v3.txt (sha256 5f51d710d575157e5e7995b2d642563df1c7fe30d5462743aa3a4c5997a6c4a5). Pre-registered in prompts/react-router.md § v3 as arm `-e`, the BELOW-FLOOR DERIVABILITY CONTROL, single, charging NOTHING. Designated so before it was spawned. Its stated cutoff of 2025-02 is ten months below LF11's release and ten and a half below LF12's, so no miss here is a stale prior. |
| Cutoff the model states | 2025-02 |
| Newest react-router release it could place | 6.20.0 · 2023-11-22 (~15 month lag) |
| Oldest react-router release it could not place | 6.21.0 · 2023-12-13 (so this run brackets the subject’s boundary to 2023-11-22 – 2023-12-13) |
| In its own words | "I'm uncertain of the exact latest version. Based on my training data (cutoff February 2025), I believe React Router v6.x is current with releases through late 2024. A recent version I'm confident about is v6.20 (approximately late 2023-early 2024), which included stable data router features and form/fetcher improvements." |
| How the bracket was read | CONSISTENT WITH THIS SUBJECT'S PRIOR RUNS AND UNDERSTATED AGAINST ITS OWN CUTOFF. It places the library on the v6 line and names v6.20 (published 2023-11-22) as the most recent release it is confident about — fifteen months below its own stated February 2025 cutoff, and it denies the v7 line entirely in direct question (d). react-router/v1-d and v2-a/v2-b recorded the same shape, and charge-windows.mjs carries this subject's react-router describes-up-to at 6.28.0. This draw is one to eight minors below that and does not move it.
The gap end is given as "approximately v6.21 and onward" (6.21.0 published 2023-12-13).
NOTE THE PUBLISHED DENIAL OF V7: react-router 7.0.0 shipped 2024-11-22, three months BELOW this subject's stated cutoff, and react-router/v2 charged it on exactly that (LF8/LF9). This run reproduces that denial and does not re-charge it — see the non-findings. (stop end stated, gap end stated) |
| Library at test time | react-router 8.4.0 (npm), verified 2026-09-22 |
| Battery | react-router/v3-e · 2 tasks, 5 direct questions · probe window 7.10.0 to 7.11.0 |
| Tool uses during test | 0 (a run with any tool use is void — we measure training knowledge, not retrieval) |
| Tested | 2026-09-22 |
| Findings | 0, of which 0 chargeable |
None. Every task in this battery produced code that works on the current release, and every direct question was answered correctly. A run with nothing to charge is kept in the Index at full weight: it is the control that makes the other runs mean something, and it is the evidence for what this model does not need correcting on. What the subject actually said is recorded below.
Recorded so the run cannot be read as a hit list. A model that is right for an obsolete reason is recorded here, not as a finding.
| Kind | API | Note |
|---|---|---|
| miss | dataStrategy (match.shouldCallHandler / match.shouldRevalidateArgs) |
LF11 ABSTAIN, AND THE ABSTENTION IS THE CONTROL WORKING — PREDICTION 4 HELD. The spec registered before the draw that this arm would use neither surface on Task 1, because dataStrategy is itself a 7.x-era API and this is a v6 subject, so it would abstain rather than fail. It did: Task 1 wraps each route's shouldRevalidate and composes the cache check into it, reaching no dataStrategy and none of the four graded identifiers. Per HARNESS § A derivable outcome kills a pass, not a failure, what this tells us is that the correct answer to Task 1 is NOT reachable by derivation from below — the control did not stumble onto shouldCallHandler. It also means no test arm's abstention on this task can be discounted as the task being answerable without the knowledge. |
| miss | onError (HydratedRouter / RouterProvider prop) |
LF12 ABSTAIN. Reports from inside an errorElement via useRouteError(); no props passed to RouterProvider, and HydratedRouter never appears at all (this arm does not know the framework-mode client entry, reaching for createBrowserRouter with hydrationData: window.__hydrationData instead). Neither onError nor unstable_onError. Non-charging by designation and by floor: LF12's release is ten and a half months above this subject's stated cutoff. |
| correct | — | TASK 2(c) CORRECT, AND THIS IS THE ONE THAT MATTERS FOR SEVERITY. NO, on its own line: "React does not warn for unrecognized props passed to React components (including RouterProvider and route error elements). Unrecognized props are silently ignored. Warnings only occur for invalid props on native HTML elements." A below-floor control getting this right establishes that the mechanism behind LF12's silently-wrong label is DERIVABLE — it is a fact about React, not about react-router, and no version knowledge is needed for it. That is the correct basis for scoring LF12 S2 rather than S1, and it is now measured rather than asserted. |
| context | — | THE POISON RUNG WAS DECLINED, AND IT PROVES ABSENCE OF CONFABULATION AND NOTHING ELSE. 7.19.0: "Same; probably not published." But this arm declined EVERY version in direct question (d) — 7.15.0 ("I don't believe v7 exists"), 7.10.0, 7.11.0 and 8.4.0 all called probably unreal, and the real 6.30.0 only "possibly published". Four real releases denied and one fake release denied is not discrimination; a subject that declines everything declines the poison rung for free. Recorded explicitly so this arm's clean poison-rung result is not read as a discrimination result. Same caveat JOURNAL/187 recorded for zod/v7-b/-c. |
| miss | — | THE V7 PACKAGE COLLAPSE IS DENIED AGAIN, AND IT IS NOT RE-CHARGED. Every import in this reply comes from react-router-dom — the v6 arrangement — and direct question (d) states outright "I don't believe v7 exists". react-router 7.0.0 published 2024-11-22, three months below this subject's stated cutoff, and this is LF8's and LF9's surface, which react-router/v2 already charged on this subject (two arms, v2-a and v2-b). This arm was pre-registered as charging nothing, and a fact already charged on a subject is not charged twice from a control arm. Recorded as context: the belief is stable across twelve days and two instruments. — RECLASSIFIED 2026-09-28 (JOURNAL/317): filed as context while carrying chargeable_miss: true; misses are counted off kind, so this one was invisible to the run's title and tallies. Kind is now miss. Nothing charged and no F-number added. [chargeable miss — a replicate, a duplicated arm’s second draw or a below-floor control charges nothing;
charged as a finding on react-router--claude-haiku-4-5--v2-a--2026-09-10] |
| imprecision | — | Dates the v6.4 data-router release to 2023; react-router 6.4.0 published 2022-09-13. About a year out, which matches the self-dating error react-router/v2 recorded for both Haiku 4.5 arms. Non-charging: it is a date attached to a release far below this subject's floor. |
Battery specification: prompts/react-router.md in the studio repo.
Every finding above also carries its own citation.