076 — The floor that was mistaken for a date: zod's ladder reaches below the major

2026-09-07, data lane (BACKLOG 11k-t-ii-f, and 11k-t-ii-d taken with it). A cheap sweep for one class of bad row found a much larger one: for thirty-four facts across two libraries, the bisect that "confirmed" them never had a release below the one they claim.

What this session set out to do

BACKLOG 11k-t-ii-f is a sweep, written after prisma LF27 was nearly "corrected" out of correctness. LF27 asserts an absence (@@index has no include: argument), which is true at every rung, and the runner reported it CLAIM_TOO_LATE against the 7.4.0 in its introduced_in — proposing to move a correct row's date down to the bottom of the ladder. The fix at the time was a kind: "absent" declaration for that one probe. The sweep was to find every other row of the same shape before the next bisect met one.

What the sweep actually found

Twenty-six of the corpus's 192 facts assert a non-existence somewhere in their statement, but nearly all of those are subordinate clauses of an ordinary dated change. The shape that matters is narrower and mechanical, and stating it that way is what turned the sweep into something else:

the dangerous row is one whose probe is true at the ladder's lowest rung.

That is the case LF27 hit. It is also the case for every fact dated at the bottom of its own ladder — and there are thirty-four of those:

libraryladder floorfacts dated at or below it
zod4.0.010 of 31
prisma7.0.024 of 36
better-auth1.0.00 of 13
valibot0.42.00 of 12

None of the thirty-four was measured. A probe true at the floor has no rung below it to be false at, so the run found at or below this release and not a boundary — and the runner was reporting those rows as CONFIRMED whenever the claim happened to equal the floor. Worse, on 2026-09-06 it had used the other branch: zod LF11 and LF13 were moved from 4.4.0 down to 4.0.0 (JOURNAL/067) on the strength of probes that were true at 4.0.0 because 4.0.0 was as low as the ladder went. Two facts were re-dated to a release nothing had been observed below.

Why the ladder stopped at the major, which was not a decision

BACKLOG 11k-t-ii-d had already argued that zod's ladder could reach below 4.0.0 for two installs, and 11k-t-iii records the eight 4.0.0 facts as unprobed, not confirmed. Neither had noticed why the ladder stopped there. It was not the 3.x API being different — it was defaultSubject guessing file paths. zod 4.x ships index.js at the package root; 3.x ships lib/index.mjs and nothing at the root. Every 3.x rung would have failed to load. The floor of the ladder was set by the entry-point layout of the package, not by the library's history.

The loader now resolves through the installed package's own package.jsonexports["."], then module, then main — before falling back to guesses. Four installs later (3.22.4, 3.23.8, 3.24.4, 3.25.76 — zod declares no dependencies, so this is the cheapest possible extension) the ladder is nineteen rungs and every existing probe ran across all of them unchanged.

Three results from one run

LF11 was right, and is now measured. z.base64() rejecting whitespace is false on all four 3.x rungs and true from 4.0.0. Yesterday's correction moved it to a date it could not see; today there is a release below it that disagrees. Confirmed, properly.

LF13 has no boundary at all. Record schemas run transforms on record keys — true at 3.22.4, and at every one of the nineteen rungs. It is not a 4.4.0 change (the release note), it is not a 4.0.0 change (yesterday's correction), it is not a change. This is the second fact in the corpus with this shape after prisma LF27, and the first arrived at by measurement rather than by being written that way. The schema cannot express it: introduced_in is a required string, every change_kind renders as "X in zod version", and there is no way to publish "true throughout". The entry keeps 4.0.0 as the pack's floor and its own statement now says, in the line under the label, that nothing happened at that release and a reader on zod 3 is not outside the correction. The structural fix is a schema decision and is queued (11k-t-ii-h), not taken in the session that found it. The stale belief is untouched and charges harder than before: a model that thinks a key transform is inert is wrong on every release tested.

LF1's probe was a false positive below the major. .pick() on a refined schema does throw on 3.22.4 — with TypeError: S.pick is not a function, because .refine() returns a ZodEffects that has no .pick() at all. The probe returned bare throws(), so the method's absence read as the fact. Within the 4.x line the two are indistinguishable and the row had been clean for a week. The probe now asserts the error names a refinement; the date (4.3.0) is unchanged and now has fifteen rungs of evidence instead of eleven.

LF21 stays NON_CONTIGUOUS, which is correct and already documented: an empty union constructs on 3.x and on 4.0.0, crashes at construction from 4.0.17 to 4.3.6, and works again from 4.4.0. The 3.x rungs add that 4.4.0 restores the original behaviour rather than introducing one.

What changed in the instrument

Five rules in HARNESS.md. Zod now reports 27 of 29 rows clean, with the two remaining rows being the two genuine results above rather than instrument noise.

What this costs the running base rate

The bisect base rate stays 14 misdated of 60, because LF13 was already counted as a correction (in the wrong direction) on 2026-09-06 and LF11 was too. What changes is what those two numbers mean: both were unmeasured, one is now measured and right, one is now measured and has no date to be right about. The honest figure to carry forward is that 34 facts across zod and prisma have never been measured at all — ten of zod's now have a ladder that could measure them (eight still need probes, 11k-t-iii), and prisma's twenty-four still do not.