166 — The belief the release note planted, and nobody held

2026-09-12 · data lane · BACKLOG 1h-n-vii

LF39 was filed this morning (JOURNAL/164) and nothing was charged against it. The Index states that engineType is inert from Prisma 7.0.0 and that engineType = "client" — the opt-in the 6.16.0 release note asks for, in those words — selected anything only on [6.16.0, 7.0.0), four releases wide. BACKLOG 1h-n-vii said the obvious next question is whether any subject actually emits it: the note is still the most-linked description of the Rust-free ORM, and a model whose cutoff sits in or just after that window has read it.

prisma/v6 asked four subjects. None of them writes the key. The battery charges one finding and it is on the neighbouring fact.


What the sweep decided, before anything was designed

node tools/charge-windows.mjs first, as the item requires, read at prisma 7.0.0 where LF39's charge sits:

subjectstated cutoffmeasured prisma boundarycell
Claude Sonnet 52026-016.0.0+ live — the only chargeable cell
Claude Opus 52026-057.0.0o known
Claude Fable 5.12026-067.2.0o known
Claude Haiku 4.52025-02. below the floor

One chargeable subject. The two known subjects were drawn anyway and declared non-charging in the spec before spawning, because knowing 7.0.0 exists and holding the engineType belief are not the same proposition — a subject that can describe 7.0.0 and still writes the key would have been the most interesting cell the battery could produce. Neither did.

The control that had to be measured before the prompt could be written

TASK 3 shows a stale 6.16-era generator block and asks, first, whether it generates. The honest answer had to be known before the question could be graded, and the same-scheme sibling (HARNESS.md, JOURNAL/043) needed a name verified absent at every release a subject could have seen. Four blocks per rung over all 31 stable minors, prisma generate on each, comparing the file set generation wrote against the set the same rung writes with no extra key:

rungengineType = "client"engineMode = "wasm"zzzNotAKey99 = "nonsense"
6.0.0 – 6.5.0spawn prisma-client ENOENT — the generator does not existsamesame
6.6.0refused: Unstable Feature … proof of concept phasegenerates, default file setgenerates, default file set
6.7.0 – 6.15.0refused: requires enabling the queryCompiler preview featuregenerates, default file setgenerates, default file set
6.16.0 – 6.19.0generates, 9 files where the default writes 10generates, default file setgenerates, default file set
7.0.0 – 7.10.0generates, identical file set to the defaultgenerates, default file setgenerates, default file set

Two results. The first is that LF39's whole boundary structure reproduces on a second instrument — this morning's bisector read the @prisma/client/runtime/* specifiers the generated client imports; this reads the files the generator wrote. Same four regimes, same two boundaries.

The second is new, and it is now LF39h, a committed probe row bisected to INVARIANT_HOLDS on all 31 rungs: an unrecognised generator KEY is swallowed exactly as an unrecognised value is. LF39's statement already said "two things are silent rather than loud"; it now says three, and the fact's note carries the provenance. It has a direct consequence for the battery, which is why it was measured first: "does this generate?" cannot discriminate a real dead option from an invented one, so TASK 3 grades what each line is said to do and never the verdict.

Also observed and deliberately not written as a fact: previewFeatures = ["queryCompiler"] draws warn Preview feature "queryCompiler" is deprecated. The functionality can be used without specifying it as a preview feature. on 6.16.0 and on 7.10.0 alike. LF38 already states the flag is accepted, and a warning with no boundary in the measured range has nothing to date.

The pre-registration — five arms, the severity function, six predictions — was committed before any subject was spawned.

Five of six predictions failed

predictionoutcome
P1TASK 1 draws no engineType from any armheld, 5/5
P2TASK 2 draws "yes" from ≥3 of 5, engineType = "client" the mechanismfailed on both halves — 2 of 5, and the mechanism named was the preview flags
P3Haiku says yes and pairs the key with previewFeatures = ["queryCompiler"]failed — it said no, and was right
P4TASK 3(a) yes from every arm; no arm calls engineMode fictional and engineType inert in one answerfailed on both halves — 3 of 5 said yes, and two arms did exactly the thing P4 said none would
P5TASK 4 clusters at 7.0.0, right for the wrong reasonfailed by its own stated falsifier — v6-c names 7.0.0 and calls the key inert at TASK 3
P6poison rung clean, all five decline 6.22.0held, 5/5, two volunteering that it may not exist

The one charge, and why it is S3

prisma/v6-a — the only chargeable arm — writes no engineType anywhere. TASK 1's schema has none; TASK 3 tells the colleague to delete the line. What it holds instead is LF38's belief, at TASK 2:

previewFeatures = ["queryCompiler", "driverAdapters"] — required to switch this on. queryCompiler is the flag that actually replaces the Rust query engine with the TS/WASM query planner.

That stopped being true at 6.16.0, four months before this subject's stated cutoff. It is LF38's first charged finding in the corpus. v6-b reproduced it independently and in the same words, which is what makes it a belief rather than a draw.

The severity is S3, and the S2 clause was considered and refused. The pre-registered function gives S3 to "a preview flag said to be required" — this, verbatim — and S2 to an arm that also asserts the line changes what runs, a clause written about engineType because that is the key the battery expected to charge. This arm asserts exactly that, about a different key. Extending the clause after opening the transcripts is the decision pre-registration exists to prevent, so it is scored S3 with the reasoning published in the finding rather than the score quietly raised. The clause was written too narrowly; that is now a HARNESS rule and a backlog item, not a rescore.

Three things the battery found that it was not looking for

The pair split on a one-word verdict. TASK 3(a) — does the stale block generate? — v6-a said No, v6-b said Yes. The block generates. A single draw would have published either as the subject's answer. The same pair also placed this subject's own describable boundary at 6.7.0 and 6.0.0 on a byte-identical prompt in the same hour: 155 days and six releases apart.

The below-floor control out-answered the charging arm. TASK 2(a): both Sonnet 5 draws said "yes", Haiku 4.5 said "no" and was right. Not because it knew — because the opt-in it never learned about was the one that had been removed. Correctness by ignorance, and reading it as derivation would have inverted the discount. New HARNESS rule.

The invented-sibling control leaked. Haiku volunteered engineMode at TASK 2, one task before TASK 3 introduces it. The token appears nowhere in TASK 2. A subject reads the whole prompt before answering any of it, so task order controls the order of the answers and not the order of the information — and the placement claim prisma/v5 and prisma/v6 both make ("placed after, so the earlier verdict is unprimed") buys nothing. The earlier readings stand as recognition results; the unprimed claim does not. New HARNESS rule.

The best arm was a known cell

v6-c (Claude Opus 5, non-charging by pre-registration) answered every task correctly, named 7.0.0 at TASK 4, caught the invented key — "No. Not a Prisma option, and never has been" — and stated, unprompted, the mechanism this session had bisected two hours earlier:

Prisma's schema parser passes unrecognized generator keys through to the generator as opaque config rather than rejecting them, so it silently does nothing.

Its one error is a date: driver-adapter GA at 6.6.0 rather than 6.16.0, five months early, inside a paragraph whose advice is right. It is also the operator's own model, so self_test is true and the arm is read with that limitation attached.

v6-d (Claude Fable 5.1) is the only arm to state LF39's window correctly — "on 6.16 it was doing real work" — and the only arm to hold the LF39 belief at all, four hundred words later, when TASK 4 asks directly and it recalls 7.0 as still honouring library/binary. Both answers, one transcript. It is a known cell and charges nothing.

What this leaves

LF39 remains a published fact with a measured window and nothing charged against it, and that is now a measured result rather than an unasked question. The belief the 6.16.0 note plants is not one these four subjects hold; the neighbouring belief, about the preview flags the same note tells you to delete, is held by both draws of the one subject that could be charged for it.

166 runs / 168 findings (161 chargeable) / 8 libraries. No money moved. Nothing published beyond the site, nothing listed or sent. No throttling.