Run prisma--claude-haiku-4-5--v4-f--2026-09-06
The far control, fourteen months below the probe window, and it got MORE right than the near control — one reachable probe and one unreachable one against the near control's zero and one. That confirms P4 and re-confirms JOURNAL/057's finding that distance below the floor does not order what a control produces, in the inverted direction for the second battery running. But the manner matters more than the count and it cuts against reading either hit as a derivation. This draw asserted "Prisma supports nested transactions via savepoints under the hood" and "the queryPlanCacheMaxSize option is a valid configuration parameter" flatly, with no hedge, from a stated February 2025 cutoff — thirteen months before either feature shipped. Both happen to be true now. Neither could have been known, and the same confident register produced a false claim in the same breath: that "if the outer transaction fails, the entire nested transaction is rolled back automatically" was already true, and that node-postgres prepared-statement caching "happens automatically when the same query string is reused" and is "managed transparently by the adapter", which is the opposite of the shipped default. This is the guessing control finding guessing — the first time in three batteries — and it lands the reachability pre-sort in a worse place than a null result would have: the sort's two exceptions are one control that knew something unreachable and one control that guessed.
| Subject | Claude Haiku 4.5 claude-haiku-4-5, Anthropic |
|---|---|
| Invoked as | Agent tool, model alias "haiku"; prompt sent verbatim from prompts/sent/prisma-v4.txt. FAR BELOW-FLOOR CONTROL, pre-registered as never charging. Its stated cutoff is thirteen to fourteen months below the probe window. First prisma run for this subject. |
| Cutoff the model states | 2025-02 |
| Newest prisma release it could place | not established in this run |
| In its own words | "For the most recent Prisma 7 minor release, I cannot reliably state a specific version number without risking inaccuracy." |
| Library at test time | prisma 7.10.0 (npm), verified 2026-09-06 |
| Battery | prisma/v4-f · 7 tasks, 4 direct questions · probe window 7.5.0 to 7.8.0 |
| Tool uses during test | 0 (a run with any tool use is void — we measure training knowledge, not retrieval) |
| Tested | 2026-09-06 |
| 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 | queryPlanCacheMaxSize |
UNREACHABLE PROBE U1, from fourteen months below. Task 2(i): "Yes." "Set queryPlanCacheMaxSize: 0 in the PrismaClient constructor to disable the cache entirely... you could also cap the cache size to a reasonable number (e.g., queryPlanCacheMaxSize: 500)." It produces the exact option name, unprompted, before task 7 supplies it. Recorded as correct because it is correct; read the run summary for why it is not read as knowledge. |
| correct | tx.$transaction() |
REACHABLE PROBE R3, from fourteen months below. Task 5(i): "Yes. Prisma supports nested transactions via savepoints under the hood. If the outer transaction fails, the entire nested transaction is rolled back automatically." 7(c): "Yes." The only arm in the battery to get R3 right, and P3 — which predicted every arm would get it from SQL semantics — is falsified in the other direction: only the arm that could not have known it said yes. |
| miss | prisma postgres link / new PrismaPg(connectionString) |
REACHABLE PROBES R1 and R2, both denied. Task 1(i) "No"; task 3(i) "No", with 7(a): "The PrismaPg constructor does not accept a raw connection string; it requires a Pool instance from node-postgres." Note it is the only arm that names Pool alone rather than Pool | PoolConfig, which is the 6.x-era shape. (Below-floor control, pre-registered as never charging.) |
| miss | statementNameGenerator |
UNREACHABLE PROBE U2, denied with a positive false claim of the kind the near control avoided: "Prepared statement caching in node-postgres happens automatically when the same query string is reused. There is no documented option on the PrismaPg adapter to control statement names. The caching behavior is managed transparently by the adapter and the underlying node-postgres pool." The shipped declaration says the opposite about the default, and the option exists. (Below-floor control, never charges. Recorded because it is the clearest evidence that this arm's two hits are the same register as its misses rather than a different one.) |
| miss | prisma bootstrap |
UNREACHABLE PROBE U3. Task 6(i): "No... This is a multi-step process; there is no single orchestrating command." (Below-floor control, never charges.) |
| context | — | POISON RUNG, direct question (c): "I do not know if this command exists in the Prisma CLI; I am not aware of it in stable Prisma 7" — the same answer for link and for branch. Declines to assert. P6 holds, 6/6. Its boundary answer is the loosest in the battery: "the most recent Prisma release whose contents I can reliably describe is Prisma 7 in its early-to-mid 2025 state (core adapter system, interactive transactions, query plan caching, the pg adapter)" — Prisma 7 shipped 2025-11-19, so this places a release nine months before it existed and attributes query plan caching (7.4.0, 2026-02-11) to it. |
Battery specification: prompts/prisma.md in the studio repo.
Every finding above also carries its own citation.