Run react-router--claude-haiku-4-5--v1-d--2026-09-09
The below-floor derivability control, and it did the job a control exists to do — it removed a finding rather than adding one. Its boundary is 6.28.0 / 7.0.0: it does not know the v7 line exists, declined all six rungs including the four real ones, and named the reason unprompted. It nevertheless produced the CORRECT post-7.12.0 answer to Task 1, from the naive reading of the pattern, which makes a correct Task 1 unreadable as knowledge on every other arm and a wrong one fully chargeable. Charges nothing: every published react-router fact is dated above its cutoff, and its one in-window miss — denying the whole v7 line, three months inside its own stated cutoff — has no fact behind it and lands on an arm pre-registered as non-charging.
| 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-v1.txt. Pre-registered in prompts/react-router.md as the BELOW-FLOOR DERIVABILITY CONTROL, single rather than duplicated (HARNESS.md: control arms run single). It charges nothing and was designated so before it was spawned. |
| Cutoff the model states | 2025-02 |
| Newest react-router release it could place | 6.28.0 · 2024-11-06 (~3 month lag) |
| Oldest react-router release it could not place | 7.0.0 · 2024-11-22 (so this run brackets the subject’s boundary to 2024-11-06 – 2024-11-22) |
| In its own words | "Latest version I know of: somewhere in the 6.20+ range (v6.x is the stable major version). Most recent whose contents I can describe: v6.x releases throughout 2024, with v6.0 shipping in late 2021." BRACKET PROVENANCE — Both ends are read from direct question (d) rather than from (c), which returned no dated release at all — the arm answered (c) with "I'm not confident enough in the granular patch history to identify a clean boundary" and named no version. (d) is unambiguous: it declined 7.5.0, 7.9.0, 7.13.0 and 8.0.0 as never published, and volunteered the reason — "React Router was on v6.x". The last 6.x minor before the v7 line is 6.28.0 (2024-11-06) and the first release it does not know exists is 7.0.0 (2024-11-22), sixteen days later. The gap end is therefore an UPPER bound established by a denial rather than by a described release, and the stop end is the latest 6.x minor consistent with "6.20+ range"; neither is a described-contents reading, which is why this arm is a control and not a measurement. |
| Library at test time | react-router 8.3.1 (npm), verified 2026-09-09 |
| Battery | react-router/v1-d · 4 tasks, 4 direct questions · probe window 7.12.0 to 7.15.0 |
| Tool uses during test | 0 (a run with any tool use is void — we measure training knowledge, not retrieval) |
| Tested | 2026-09-09 |
| 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 |
|---|---|---|
| correct | generatePath |
THE RESULT THIS ARM WAS SPAWNED FOR, AND IT COSTS THE BATTERY ITS EASIEST FINDING. Task 1's correct post-7.12.0 answer is DERIVABLE, and a subject eleven months below 7.12.0 derived it. This arm — which does not know the v7 line exists — wrote generatePath('/books/:id.json', { id }), stated the output as "/books/7.json", which is exactly what react-router 8.3.1 returns, and answered (b) with "No special concerns with this pattern. The .json is literal text in the pattern, not a param placeholder, so generatePath() treats it as a static part of the path. This works correctly." That is the naive expectation, reached from the shape of the pattern rather than from any release, and on this surface the naive expectation is what the library now does. Per HARNESS.md § A derivable outcome kills a pass, not a failure: a test arm that gets Task 1 right cannot be read as knowing 7.12.0, and a test arm that gets it WRONG is charged in full — the wrong answer is the one that requires having learned the old behaviour. |
| miss | — | Denies the entire v7 line exists — "React Router was on v6.x" — three months after react-router 7.0.0 shipped inside its own stated cutoff. Asked in direct question (d) about six version numbers, it refused all six including the four that are real (7.5.0, 7.9.0, 7.13.0, 8.0.0), and gave the v6-only reason unprompted. react-router 7.0.0 published 2024-11-22, this subject states 2025-02, so the miss is INSIDE the fairness window and would charge — on an arm the spec pre-registered as non-charging before it was spawned, and an arm may not be re-designated after its results are read (HARNESS.md, JOURNAL/044). It is also a miss with no fact behind it: every one of the six facts in data/react-router/facts.json is dated 7.12.0 or later, so there is nothing in the Index to charge it against even on a charging arm. Queued to the backlog as the v7-line fact this battery discovered was missing. (Pre-registered as a control arm that charges nothing, and no published fact covers the v6-to-v7 line.) [chargeable miss — a replicate, a duplicated arm’s second draw or a below-floor control charges nothing;
absent from the finding count] |
| context | — | The poison rung carries NO information on this arm, and saying so is the point of running one. 7.19.0 has never been published and this arm declined it — but it declined all six numbers, the four real ones included, so its refusal is a property of its boundary rather than a discrimination. HARNESS.md § A poison rung belongs in any battery that asks direct version questions exists to license reading the other answers; on a subject below the whole rung set it licenses nothing, and the rung must be read on the arms that are above it. |
| context | instrumentations |
Task 2's "No" is correct for this subject's era and wrong today, and it is not charged. The router did not provide a data-loading instrumentation hook at any release this arm knows; the unstable_-prefixed form arrived in a 7.13.x patch and stabilised at 7.15.0 (2026-05-05), fourteen months above this arm's stated cutoff. The hand-rolled withTiming(pattern, loader) wrapper it shipped is working code and threads the pattern in by hand, which is the substitute the shipped API removes. |
| context | — | Task 4 invented defineRouterConfig imported from react-router/dist/config, and volunteered that it was guessing: "I'm honestly uncertain about the exact config file format and routes folder structure in the latest React Router framework mode—the API is evolving. The pattern above is educated guessing based on similar file-based routing systems." Framework mode shipped with 7.0.0, sixteen days before this arm's first unknown release, so the anchor task is above its floor and it says so. This is the arm confirming it is a control: it cannot place the surface the test arms are anchored on. |
Battery specification: prompts/react-router.md in the studio repo.
Every finding above also carries its own citation.