Run prisma--claude-opus-5--v1r-a--2026-09-01 · self-test: the subject is the operator
Replicate A of prisma/v1 against Opus 5, prompt unchanged. It placed its describable boundary at prisma 7.0.0 (2025-11-19) and attributed the release correctly, agreeing with prisma/v1 — and disagreeing with its own concurrent, blind twin v1r-b by 204 days. Pre-registered outcome C, on the library that was predicted to produce outcome A. No findings are charged; the code half is reported as prose because prisma/v1 already carries this subject's findings. The code diverged from v1 even where the self-report agreed: this draw wrote 6.x-primary code with labelled 7.x deltas, where v1 wrote the 7.0 forms outright.
| Subject | Claude Opus 5 claude-opus-5, Anthropic |
|---|---|
| Invoked as | Agent tool, model alias "opus", no tools available to the subject |
| Cutoff the model states | 2026-05 |
| Newest prisma release it could place | 7.0.0 · 2025-11-19 (~5 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 | "Latest I know of: Prisma ORM 7.x. I'm confident 7.0 exists (GA around Nov-Dec 2025); I cannot name the current 7.x minor, and by May 2026 there are certainly several I know nothing about. Most recent release whose contents I can describe: 7.0 at headline level only (new generator default, Rust-free by default, prisma.config.ts, ESM, Node 20+). ... First release I know only as a version number: effectively anything after 7.0 — I'm aware 7.x minors must exist but cannot describe a single one." |
| Library at test time | prisma 7.10.0 (npm), verified 2026-09-01 |
| Battery | prisma/v1r-a · 10 tasks, 4 direct questions · probe window 6.18.0 to 7.0.0 |
| Tool uses during test | 0 (a run with any tool use is void — we measure training knowledge, not retrieval) |
| Tested | 2026-09-01 |
| 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 | — | The measured quantity, and the reason this run exists. This draw placed its describable boundary at prisma 7.0.0 (2025-11-19) and attributed the release's contents correctly: the prisma-client generator becoming the default with the client generated into the source tree, the Rust-free client by default, prisma.config.ts as the standard config surface, removal of the package.json#prisma key, and a Node 20+ floor. Every clause is true of 7.0.0 per the vendor's release notes and upgrade guide, so this is content-level attribution rather than a recognised version string. It agrees with prisma--claude-opus-5--v1--2026-08-31 and disagrees with its own concurrent twin v1r-b by 204 days. (A correct answer is not a stale prior. It is recorded because the boundary, not a failure, is what this run measures.) |
| context | — | Tasks 1-10 produced code but no charged findings, per the v1r pre-registration: prisma--claude-opus-5--v1--2026-08-31 already carries this subject's seven prisma findings and counting the same failure twice would inflate the dataset. The code behaviour still diverged sharply from v1 and is reported in the markdown. In short: where v1 wrote the 7.0 forms as its primary answer — provider = "prisma-client" with an output path, an import from the generated directory, a PrismaPg adapter — this draw wrote the 6.x forms as primary (provider = "prisma-client-js", import { PrismaClient } from '@prisma/client', new PrismaClient(), a postinstall: prisma generate hook, "prisma": { "seed": ... } in package.json) and appended a labelled "7.x delta" to most answers. Under the battery's v6-escape-hatch rule the labelled deltas are correct rather than stale, but a developer copying the primary block gets code that does not run on 7.0.0. (Pre-registered: a replicate re-sends the code tasks only to hold the priming constant, and does not re-charge what the original run already charged.) |
| imprecision | prisma migrate diff |
Task 8 produced migrate diff --from-url ... --to-schema-datamodel ... --script. Both --from-url and --to-schema-datamodel were removed in 7.0.0 in favour of --from-schema and --from-config-datasource. This is the same surface v1 already charged, so it is recorded here as evidence of code-level agreement between the draws rather than as a new finding. (Already carried by the run this replicates; re-charging would double-count.) |
v1r-b were given a byte-identical prompt, the same model alias, on the same day, running concurrently, and placed the boundary 204 days apart (7.0.0 / 2025-11-19 here; 6.7.0 / 2025-04-29 there). Prisma was pre-registered as the library expected to replicate tightly, on the reasoning that its version history is unambiguous where langchain's is not. That reasoning is now falsified. — openBattery specification: prompts/prisma.md in the studio repo.
Every finding above also carries its own citation.