Run prisma--claude-haiku-4-5--v7-e--2026-09-27
The control did not do what P1 predicted: it wrote satisfies, not Prisma.validator, so the correct form is reachable from a February 2025 cutoff and TASK 1 does not discriminate by date on its own. It then answered TASK 2 correctly for an invented reason — a removal in Prisma 5 that never happened — which is the corpus's standing warning about this control: a right verdict from below the floor is evidence of nothing.
| Subject | Claude Haiku 4.5 claude-haiku-4-5, Anthropic |
|---|---|
| Invoked as | Agent tool, model alias "haiku" (prompts/sent/prisma-v7.txt (3,698 bytes, md5 87643f2f8580cb03f4ba7513a88f9782), committed and pushed at 1b046af before any subject was spawned). The below-floor derivability control: its stated cutoff is seven months below 6.16.0. Identity asked after the draw: "I am Claude Haiku 4.5, model ID `claude-haiku-4-5-20251001`" — recorded under claude-haiku-4-5, the id this subject's earlier prisma runs carry. |
| Cutoff the model states | 2025-02 |
| Newest prisma release it could place | not established in this run |
| In its own words | "The latest version I can name is v6.x (I believe v6 is current as of my cutoff)." |
| How the bracket was read | The arm puts its newest describable release at "roughly v5.8 or v5.9 (early 2024)" and says it knows v6 exists without being able to describe it. The Index's prisma ladder and releases.json start at 6.0.0, so a 5.x reading cannot be dated against them; both ends are recorded null rather than dated off a range the snapshot does not hold. |
| Library at test time | prisma 7.10.0 (npm), verified 2026-09-27 |
| Battery | prisma/v7-e · 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. Below the floor, so this is the pre-registered derivability reading: satisfies is reachable from a February 2025 cutoff — for this task it was never version-dependent — and P1 (that this arm would write Prisma.validator) is falsified. (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.) |
| context | import { PrismaClient } from '@prisma/client' |
TASK 1 imported Prisma and PrismaClient from @prisma/client, although the prompt's generator block sets provider = "prisma-client" and an output path. That is LF5's surface (import from the generated output path, not @prisma/client) and the pre-registered generator-switch outcome. (Pre-registered as a non_finding, not charged on this battery; the arm is below the floor in any case. The as-written specifier was NOT graded: on this rung @prisma/client resolves to a client another probe generated into node_modules/.prisma, so a compile there would read the wrong client and is not a measurement.) |
| miss | Prisma.validator |
TASK 2 answered "No" — right at the current release — for an invented reason: "Prisma.validator was removed in Prisma v5 (released mid-2023, roughly)", and TASK 3 repeats it: "Prisma v5.0.0 (shipped June 2023, roughly) removed Prisma.validator. It was deprecated in v4 in favor of the satisfies keyword." False: prisma-client-js emits it at every release the Index tracks (6.0.0-7.10.0), and the prisma-client generator emits it on 6.6.0-6.15.0. (Below the floor, and derivability discounts a pass, never an invention (JOURNAL/046) — so the correct "No" earns nothing, and the invented v5 removal is recorded as what it is. Not charged: control arm, TASK 2 and TASK 3 unscored, and the release it names is below the tracked range.) |
| 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). It declined all four, 6.21.0 included: "6.21.0: I cannot describe this." (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.