Run prisma--claude-fable-5-1--v7-d--2026-09-27
The subject with the latest cutoff wrote the right code and held the wrong belief. Unprimed, TASK 1 reached for satisfies; shown Prisma.validator, it said the line type-checks and that the helper is "still there through 7.x". Both are false from 6.16.0. It is the only arm of five that holds the belief, it is a known cell, and the probe it held it on is the one that names the token — so nothing charges, and the draw is the battery's clearest case that writing the current form is not the same as knowing the old one is gone.
| Subject | Claude Fable 5.1 claude-fable-5-1, Anthropic |
|---|---|
| Invoked as | Agent tool, model alias "fable" (prompts/sent/prisma-v7.txt (3,698 bytes, md5 87643f2f8580cb03f4ba7513a88f9782), committed and pushed at 1b046af before any subject was spawned). Drawn at a `known` cell (measured prisma boundary 7.2.0, above 6.16.0) and declared NON-CHARGING before spawning. Identity asked after the draw: "I'm Claude Fable 5.1, model ID `claude-fable-5-1`. I know this only from the environment/system information". |
| Cutoff the model states | 2026-06 |
| Newest prisma release it could place | 7.0.0 · 2025-11-19 (~7 month lag) |
| Oldest prisma release it could not place | 7.1.0 · 2025-12-03 (so this run brackets the subject’s boundary to 2025-11-19 – 2025-12-03) |
| In its own words | "The newest version I have any awareness of is somewhere in the Prisma 7.x line, roughly 7.1–7.3, from late 2025 into early 2026." |
| How the bracket was read | Direct (a): "The most recent release whose contents I can actually describe with confidence is 7.0.0"; direct (c): "The first release I know essentially only as a version number is around 7.1.0 / 7.2.0" — the lower of the two is recorded. Below its v6-d reading (7.2.0), which is within this subject's usual spread. (stop end stated, gap end stated) |
| Library at test time | prisma 7.10.0 (npm), verified 2026-09-27 |
| Battery | prisma/v7-d · 3 tasks, 4 direct questions · probe window 6.15.0 to 7.10.0 |
| Tool uses during test | 0 (a run with any tool use is void — we measure training knowledge, not retrieval) |
| Tested | 2026-09-27 |
| 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 | Prisma.validator |
TASK 1 wrote the selection as { id: true, email: true, name: true } satisfies Prisma.UserSelect with Prisma.UserGetPayload<{ select: typeof ... }> for the type — no Prisma.validator. It compiles on 7.10.0 and on 6.15.0. It used import type from ./generated/prisma/client and noted that Prisma.Result<...> would also work. (The anchor probe, and it passed. Graded by compiling: the arm's src/user-summary.ts, import specifier normalised to ./generated/prisma/client.js as pre-registered, compiled with TypeScript 5.9.3 (strict, nodenext) against the battery's own schema generated by the prisma-client generator on the bisector's 7.10.0 and 6.15.0 rungs. Controls in the same session: the stale artifact (Prisma.validator) OK at 6.15.0 and TS2339 at 6.16.0 and 7.10.0; the correct artifact OK on all three; a misspelled-field satisfies TS2561 on all three; a poison member TS2339 on all three.) |
| miss | Prisma.validator |
TASK 2(a) "Yes" — the colleague's line type-checks — with the mechanism stated as fact: the namespace "still exports the validator helper (it's re-exported from the runtime's public namespace, the same as under prisma-client-js)". That was true through 6.15.0 and is TS2339 from 6.16.0; the exact line was compiled on 7.10.0 this session. It still asked for satisfies instead, as style: "Not a blocker, though; Prisma.validator isn't wrong." (TASK 2 is a declared recognition probe and is never charged (pre-registered), and this arm is a non-charging known cell. It is the battery's one instance of the belief itself, and it sits in the subject with the LATEST cutoff, on the probe that names the token — while the same arm's unprimed TASK 1 wrote the correct form. Recall right, recognition wrong: the inverse of the usual gap.) |
| miss | Prisma.validator |
TASK 3: "I'm not aware of any Prisma release in which the prisma-client generator stopped providing Prisma.validator. My belief is that it is still there through 7.x." Hedged explicitly as "no removal that I know of". False from 6.16.0. (The same belief as TASK 2, on the attribution probe; TASK 3 is not scored, and the arm is non-charging.) |
| correct | — | Direct (d)'s poison rung: declined 6.21.0, which was never published (the 6.x line ends at 6.19.0 in data/prisma/releases.json, fetched 2026-09-27). "6.21.0 — I'm not even sure this release exists; I thought 6.x stopped around 6.19 before 7.0. Cannot describe." (The poison rung came back clean, which is what licenses reading the arm's other attributions at face value (JOURNAL/052).) |
Battery specification: prompts/prisma.md in the studio repo.
Every finding above also carries its own citation.