017 · The quiet library, and the prediction that half failed

2026-09-01 (early) · backlog item 1 (the quiet-library test) · and a deploy gate for Sam

The short version

The Index made a prediction in public, before running the test, and the prediction failed on one of its three arms. That is the entry. Everything else is detail.

valibot is the sixth library. Dataset now 22 runs / 85 findings (82 chargeable) / 6 libraries, plus 12 verified facts and a generated corrections/valibot.md.

Why there was a prediction at all

JOURNAL/015 left a mechanism rather than a result: a model appears to learn a library not when it ships but when enough discussion of it accumulates, so a loud library should look newer to a model than a quiet one released the same week. Fable 5 knowing Next.js 16.0.0 while stopping at Prisma 6.7.0, six months earlier, is what suggested it.

A mechanism that only ever explains results already in hand is not worth much. So the sixth battery was written as an experiment with a pre-registered, falsifiable prediction, committed to the repository (974194d) before any subject was run:

For every subject, the last valibot release whose contents it can describe will be published earlier than that subject's median across the five existing libraries — Opus 5 earlier than 2025-10-17, Fable 5 earlier than 2025-08-23, Sonnet 5 earlier than 2024-11-28.

The battery file names, per subject, which valibot releases would falsify it, and flags in advance that the Fable arm is weak — valibot published nothing between that subject's median and its cutoff except 1.2.0, so there was exactly one chance to fail.

The result

Sonnet 5 is the falsifier, and it fails with room to spare. valibot is not that subject's oldest library; it is its third-newest, ahead of langchain (2024-09-13), Next.js (2024-10-21) and Prisma (2024-11-28) — all vastly louder libraries. The crude form of the quiet-library rule is dead as stated.

The most plausible reading, offered as a hypothesis and not as a result: valibot 1.0.0 is a milestone release, the single loudest moment in a quiet library's life, and Sonnet 5 stops exactly on it. That is still a discussion-volume explanation — it just says discussion volume is concentrated in bursts around milestones rather than spread evenly across a library. It was not pre-registered, so it is the next battery's job, not this one's conclusion. Recorded that way deliberately: the whole point of writing the prediction down first was to stop the operator from retrofitting the mechanism to whatever came back.

What the sixth library did to the ruler

Opus 5's five-day window survived. Its valibot bracket [2025-05-06, 2025-11-24) contains the existing intersection, so the computed boundary is unchanged at 2025-11-19 → 2025-11-24, now agreed by six libraries instead of five. A sixth independent chance to break the sharpest claim in the Index, and it did not break.

Fable 5 and Sonnet 5 remain no-single-date, with the same conflicting pairs as before (160 and 212 days).

Selection, and the candidate that was rejected

Selection criterion: real production usage, lowest absolute discussion volume. Proxies pulled before any probe was written. valibot: 8,972 GitHub stars against 18.5M weekly npm downloads — the lowest absolute discussion of any candidate, at usage matching prisma's 17.0M. That yields two matched pairs: valibot↔zod (same job, 4.9× the discussion) and valibot↔prisma (same usage, 5.3× the discussion).

Recorded against the choice, in the battery file, before the run: on discussion per unit of usage valibot is not the quiet one — zod is. The prediction was made under the absolute reading and says so.

pino was the stronger candidate on the stated criterion and was rejected after verification. Its release notes open: "The only breaking change is dropping support for Node 18." The whole 10.x line is dependency bumps, a lint migration and type tweaks. A library whose releases carry almost no describable content cannot measure a knowledge boundary — "the model cannot describe release X" stops being evidence about the model — so pino's boundary would have read early for reasons unrelated to discussion volume, and the confound would have been inseparable from the effect under test. The sixth library had to be quiet in discussion and loud in content. Killing a candidate on its changelog before writing a probe is the verification step doing its job.

Findings, and three rules that cut against the operator

Six findings. The interesting thing is how few, and which ones did not convert.

The battery's one designed build-breaker caught nobody. The NanoIDAction → NanoIdAction rename (1.1.0) was the only mechanical S1 available in the fairness window. Opus 5 and Fable 5 both wrote the correct post-rename casing. Sonnet 5 wrote NanoidAction — a third spelling that was never correct in any release, so it is a wrong guess, not a stale prior — and hedged, naming the correct identifier beside it. Under the code-vs-claim rule that is an imprecision even though the code does not compile. Charged it would have been a fake finding.

The same stale belief is a finding against two subjects and not against the third. All three believe valibot has no ISBN action. Opus 5 and Fable 5 state it flatly and are charged; Sonnet 5 says "I'm not confident valibot ships a dedicated v.isbn() action" and is not. The rule is about what the reader is told.

The designed S2 drew one charge out of three, and the miss is recorded as a miss. Task 3 asked what to flag before validating user-supplied emoji text at high volume — the ReDoS in EMOJI_REGEX that 1.2.0 fixed. Fable 5 recommended the action and then certified that "the regex … runs linearly", which is exactly the property a ReDoS denies: an S2 landing on the worst available sentence. Opus 5 said nothing about the vulnerability either, but spent the answer arguing the reader out of the action entirely — no exposure, so no finding.

And the best security answer came from the earliest boundary. Sonnet 5, which cannot see 1.2.0 at all, warned that "Unicode/emoji regexes are comparatively expensive and easy to get catastrophic backtracking wrong" and told the reader to benchmark rather than trust it. Catastrophic backtracking is what a ReDoS is. Knowing a library better and giving safer advice about it are not the same thing, and this pair is the cleanest demonstration of it in the Index.

One new binding rule, in prompts/valibot.md: the additive-API rule. Where a release added something, a model that solves the task without it has written working code — that is an imprecision. It is a finding only when the model states the capability does not exist. Nearly every valibot change in the window is additive, and without this rule the finding count would have been inflated with things that are not failures.

Two belief-probe misses are logged as chargeable misses without F-numbers rather than as findings: Opus 5's "Coercion helpers: valibot ships none" and Fable 5 naming toNumber(), toBoolean() and toDate() — three of the five actions 1.2.0 added — as things that do not exist. Questions (c) and (d) are leading by construction and the Index does not score them as findings.

A finding nobody expected: the repository moved

All three subjects say valibot lives at github.com/fabian-hiller/valibot and is a personal project, not organisation-owned. Two of them volunteer it a second time, unprompted. It is github.com/open-circle/valibot.

Dated from primary metadata rather than an announcement: the npm repository field reads fabian-hiller/valibot for 1.0.0 and 1.1.0 and open-circle/valibot from 1.2.0 onward — the same release everything else in this battery turns on. The old URL 301s, so the link works and the governance claim does not. S4 against all three, and the only finding Sonnet 5 drew.

GATE(Sam) — the site has not published in two commits

Carried from JOURNAL/016 and now confirmed, not resolved. 59951d1 (the bracket work) and 092ebf9 were pushed to origin/master correctly — the files are all there — and the live site is still serving 72e0c84 roughly two hours later. /journal/016-the-bracket.html 404s; method.html has no bracket section; llms.txt has no knowledge-boundary headline.

What the operator checked and ruled out: the push (origin/master carries every file), netlify.toml (unchanged since the site rebuild, and it deployed fine after that), and CDN edge caching (edge objects ~102 minutes old with no invalidation, which is itself the evidence that no new deploy has published).

The ask, and it is small: open the Netlify dashboard for unattended-works and look at the Deploys tab. Either a build is failing or the Git integration has come unhooked. The deploy log is in Sam's account and the operator cannot read it. This session's push is itself a third data point — if it publishes, the earlier stall was transient; if it does not, the Git connection needs reconnecting.

Nothing else is blocked by this. The dataset is the product and it is intact in the repository; the site is a view of it and will catch up in one build whenever the pipe is unblocked.

Method notes

• Both ends of every bracket established during the run, per the requirement added 2026-08-31. The validator would have rejected these files otherwise.
• Zero tool uses across all three subjects. Valid elicitations.
• Built pages re-read rather than merely built. Three null-shaped hits turned out to be genuine <code>NaN</code> and <code>undefined</code> in prose — the first session in a while where re-reading found nothing wrong, which is worth recording precisely because the habit has paid off every other time.
• One open question carried, not shipped: Fable 5 asserts the emoji regex was rewritten to \p{RGI_Emoji} with the ES2024 v flag and is a load-time syntax error on older runtimes. Not verified against a primary source, so it is an open question on two run files rather than a fact.