Run valibot--claude-opus-5-5--v7--2026-09-27 · self-test: the subject is the operator
A boundary ladder, not a battery: nothing charged, elicits_code: false, one arm, and the first valibot ladder. Claude Opus 5.5 states it describes valibot through 1.0.0 (2025-03-19) and holds 1.1.0 and 1.2.0 as numbers only, fifteen months below its stated June 2026 cutoff. The pre-registered prediction (1.1.0 or 1.2.0) was falsified. The stated end is equivocal: on the 1.1.0 rung it volunteered "possibly JSON parse/stringify helpers", which is LF8's 1.1.0 addition, so 1.1.0 is flagged as not a clean live window. Poison 0.43.0 and top rung 1.5.0 both NO; the demonstration task was correct.
| Subject | Claude Opus 5.5 claude-opus-5-5, Anthropic |
|---|---|
| Invoked as | Agent tool, model alias "opus"; prompt sent verbatim from prompts/sent/valibot-v7.txt (2,415 bytes, md5 34a15339511bc89219bf6791c6476b26), committed and pushed at 9b7c695 before any subject was spawned. Identity probed BEFORE the draw through the same alias in the same session, tool-free: "I'm Claude Opus 5.5 with the 1M-token context window, model ID `claude-opus-5-5[1m]`, and my training cutoff is June 2026. Both answers come from my system prompt". DISCLOSED: the operator of this studio runs on the same model, so this draw is of the operator's own model. |
| Cutoff the model states | 2026-06 |
| Newest valibot release it could place | 1.0.0 · 2025-03-19 (~15 month lag) |
| Oldest valibot release it could not place | 1.1.0 · 2025-05-06 (so this run brackets the subject’s boundary to 2025-03-19 – 2025-05-06) |
| In its own words | "The latest version I know of is about 1.2.x, and I'm not confident of that. The latest release I can actually describe is 1.0.0, which shipped around March 2025." |
| How the bracket was read | Three placements agree on the STATED boundary. The rung sort answered DESCRIBE for 1.0.0 only; NAME for 0.42.0, 1.1.0 and 1.2.0; NO for 0.43.0 (poison), 1.3.0, 1.4.0 and 1.5.0. Direct (a) names 1.0.0 as the last describable release; direct (c) states "The first release I know only as a version number is 1.1.0". BUT THE STATED END IS EQUIVOCAL, AND IN THE DIRECTION THE LADDER SPEC WARNS ABOUT: explaining its NAME on 1.1.0, the subject said "I have a vague idea it added some new actions (possibly JSON parse/stringify helpers), but I'm not sure enough to call that a description" -- and parseJson / stringifyJson in 1.1.0 is exactly LF8. So the subject declined to claim a release whose headline content it placed correctly. HARNESS § The order effect is bounded calls this equivocation, and § The boundary ladder is a standing instrument names the consequence: an under-reported boundary makes releases look live that are not. The stated reading is recorded as stated (the schema does not let a writer overrule a named version), and 1.1.0 is flagged in non_findings and BACKLOG as NOT a clean live window for this subject. Below Claude Fable 5.1 and Claude Opus 5 on this library (both 1.1.0 | 1.2.0 across valibot/v3-v6), but those were code batteries and this is the first valibot ladder, so the comparison is across instruments. (stop end stated, gap end stated) |
| Library at test time | valibot 1.5.0 (npm), verified 2026-09-27 |
| Battery | valibot/v7 · 2 tasks, 3 direct questions · probe window 0.42.0 to 1.5.0 |
| Tool uses during test | 0 (a run with any tool use is void — we measure training knowledge, not retrieval) |
| Tested | 2026-09-27 |
| 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 |
|---|---|---|
| context | boundary |
THE CELL THIS ARM WAS RUN TO FILL. Claude Opus 5.5 had never been drawn on valibot, so charge-windows.mjs printed ? for every valibot release in its column. Stated boundary: describes 1.0.0 (2025-03-19), holds 1.1.0 (2025-05-06) and 1.2.0 (2025-11-24) as numbers only. The pre-registered prediction (boundary at 1.1.0 or 1.2.0) was FALSIFIED on its own named condition, a boundary at 1.0.0 or below. It is the first of four Opus 5.5 ladders to land BELOW Claude Fable 5.1's reading on the same library (zod equal; better-auth and langchain one minor above). Consequence for the sweep: valibot 1.1.0 through 1.4.0 print as live for this subject; 1.5.0 (2026-09-09) is above its stated cutoff. See the next entry before planning against 1.1.0. |
| context | 1.1.0: parseJson / stringifyJson (LF8), hedged and correct |
EQUIVOCAL, NOT ABSENT. On the 1.1.0 rung the subject answered NAME and then volunteered "possibly JSON parse/stringify helpers" as its vague idea of the content -- the headline addition LF8 dates to 1.1.0 (2025-05-06). It also dated 1.1.0 to "mid-2025". Not credited as a description, because the subject explicitly declined to call it one; not ignored either. A battery that means to charge this subject at valibot 1.1.0 should expect LF8 to be partly known and should not count a 1.1.0 window as clean on this ladder alone. 1.2.0 carried no content at all ("probably from late 2025. I can't describe it"; shipped 2025-11-24). |
| correct | poison rung 0.43.0, and the top rung 1.5.0 |
BOTH ENDS HELD. Poison rung 0.43.0 answered NO with the correct history: "I don't think it exists. As I remember it, 0.42.x went straight to the 1.0 betas." (0.42.1 is the last 0.x; 1.0.0-beta.1 followed on 2024-10-12.) Top rung 1.5.0 (2026-09-09, above the stated cutoff) answered NO, as did 1.3.0 and 1.4.0 (inside the stated window, above the stated boundary). 0.42.0 answered NAME, correctly placed as "one of the last 0.x releases before the 1.0 betas". |
| correct | TASK 1: object, optional, picklist with a message, safeParse, flatten |
The demonstration task, answered on the 1.x surface throughout: v.object, v.optional(v.object(...)) for the nested tls, v.picklist([...], message) for the three-way mode with its own message, the message as the schema function's last argument, v.InferOutput, v.safeParse returning { success, output, issues } without throwing, and three readings of the message: result.issues[0].message, v.flatten<typeof ConfigSchema>(result.issues).nested?.mode, and v.getDotPath(issue). All of these exist on every 1.x rung. Graded CORRECT. |
| context | release history below the boundary, unchecked |
Dated 1.0.0 to "around March 2025" (2025-03-19, right to the month). Two further historical claims were NOT checked and are neither credited nor charged: that 1.0.0 added Standard Schema support, and that the move from the array-argument pipe to the v.pipe() function and the Output -> InferOutput rename happened in "the 1.0.0-beta / rc series (mid-2024 to early 2025)". The registry dates the first 1.0 beta to 2024-10-12 and 0.31.0 to 2024-06-06; no valibot fact in the Index covers either change, and the probe ladder starts at 0.42.0, so which release carried them is not established here. |
Battery specification: prompts/valibot.md in the studio repo.
Every finding above also carries its own citation.