Run prisma--claude-sonnet-5--v7-b--2026-09-27
The replicate agrees with the charging arm on everything the battery grades — satisfies in TASK 1, "no" in TASK 2, "never included" in TASK 3 — and disagrees with it by eight minors on where its knowledge of Prisma stops (6.0.0 against 6.8.0). The grade replicates; the boundary does not.
| Subject | Claude Sonnet 5 claude-sonnet-5, Anthropic |
|---|---|
| Invoked as | Agent tool, model alias "sonnet"; the same stored file as v7-a, sent blind and concurrently (prompts/sent/prisma-v7.txt (3,698 bytes, md5 87643f2f8580cb03f4ba7513a88f9782), committed and pushed at 1b046af before any subject was spawned). The born-duplicated second draw, non-charging by pre-registration. Identity asked after the draw: "Claude Sonnet 5, model ID `claude-sonnet-5`". |
| Cutoff the model states | 2026-01 |
| Newest prisma release it could place | 6.0.0 · 2024-11-28 (~14 month lag) |
| Oldest prisma release it could not place | 6.1.0 · 2024-12-17 (so this run brackets the subject’s boundary to 2024-11-28 – 2024-12-17) |
| In its own words | "somewhere in the Prisma 6.x line — I don't have a reliable specific minor to name as 'the latest.'" |
| How the bracket was read | Direct (a) names 6.0.0 as the newest release whose contents it can describe "with real confidence". Its gap end is not a release — "anything from roughly the middle of the 6.x line onward — I can't honestly point to a specific minor" — so the gap end is DERIVED as the first release above the stated stop end, 6.1.0, which is the tightest bracket the draw licenses and is flagged as a reading, not a quote. Eight minors below v7-a's stop end (6.8.0) from the same stored prompt, sent concurrently: the replicate pair disagrees on the boundary by half a year, which is this subject's documented instability. (stop end stated, gap end derived) |
| Library at test time | prisma 7.10.0 (npm), verified 2026-09-27 |
| Battery | prisma/v7-b · 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 for both names and findUniqueOrThrow with a non-null return type; both compile. (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.) |
| correct | Prisma.validator |
TASK 2(a) "no", with the mechanism (the prisma-client generator does not export validator; "Property 'validator' does not exist on type ...") and a request to compile-check before merging. The exact line was compiled on 7.10.0 this session: TS2339. (Correct at the current release.) |
| miss | Prisma.validator |
TASK 3 says the prisma-client generator never provided Prisma.validator at all, from its first preview. Measured false: the generator emits export const validator = runtime.Public.validator on every release from 6.6.0 (its first) through 6.15.0, and a reader's Prisma.validator<Prisma.UserSelect>()(...) type-checks at 6.15.0 (JOURNAL/294, re-run this session). Quote: "I believe it simply never included Prisma.validator from its earliest preview, rather than shipping it and removing it later." Both Sonnet draws hold this, blind. (Pre-registered: severity is fixed by the TASK 1 artifact alone and TASK 3 is not scored; and no fact exists to charge it against. Recorded because its DIRECTION is the opposite of a stale prior — right about the current release, wrong about 6.6.0-6.15.0 — so a reader pinned to those releases would be told a working helper does not exist. The reader_exposure field cannot carry it: 6.16.0 is published before this subject's stated cutoff, and that field's admission rule refuses a pinned-below row there.) |
| context | import { PrismaClient } from '@prisma/client' |
TASK 1 imported from ./generated/prisma, which has no index file at 7.10.0, so the specifier as written resolves to nothing. (Normalised before grading by pre-registration; LF5 is honoured (the output path, not @prisma/client), and the /client entry is not stated by any fact.) |
| 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 — cannot describe; a .21 minor would imply a very long 6.x line, which I can't confirm." (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.