Run zod--claude-sonnet-5--v3-c--2026-09-02
A below-floor control arm, charging nothing. Its job is to say which of the battery's six probes a subject that cannot know 4.4.0 gets right anyway - and the answer is two of them. It gives the pre-4.4.0 answer on the tuple default, on the z.undefined()-typed key and on the single-slash URL, which is what makes the test arm's passes on the second of those readable as knowledge. It gives the post-4.4.0 answer on the record key transform and on line-wrapped base64, which marks both probes derivable and removes them from the evidence. Its boundary reading reproduces zod/v2 exactly: last describable 4.0.0, first unplaceable 4.1.0.
| Subject | Claude Sonnet 5 claude-sonnet-5, Anthropic |
|---|---|
| Invoked as | Agent tool, model alias "sonnet", general-purpose subagent, instructed to use no tools; BELOW-FLOOR CONTROL ARM of battery zod/v3 |
| Cutoff the model states | not stated |
| Newest zod release it could place | 4.0.0 · 2025-07-10 |
| Oldest zod release it could not place | 4.1.0 · 2025-08-23 (so this run brackets the subject’s boundary to 2025-07-10 – 2025-08-23) |
| In its own words | "The most recent release I can actually describe in real detail is Zod v4.0.0, which I believe shipped stably around May 2025... My belief that '4.x' is the current major line is based on having seen the v4 announcement content directly rather than on any authoritative 'this is the latest' signal - so treat 'latest' as my last confident sighting, not a verified current state." |
| Library at test time | zod 4.5.4 (npm), verified 2026-09-02 |
| Battery | zod/v3-c · 6 tasks, 4 direct questions · probe window 4.3.0 to 4.4.0 |
| Tool uses during test | 0 (a run with any tool use is void — we measure training knowledge, not retrieval) |
| Tested | 2026-09-02 |
| 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 | z.tuple() defaults |
CONTROL READING - pre-4.4.0, as required. Task 1: "z.tuple checks the input array's length before it parses individual positions... RowSchema.parse(['widget']) throws ZodError: too_small." That is correct for 4.3.x and wrong from 4.4.0 (LF10). Not chargeable: 4.4.0 published 2026-04-29, four months past the 2026-01 cutoff this subject stated in zod/v2, and this draw stated no cutoff at all. (Below-floor control arm. A control that fails a post-cutoff probe is the control working.) |
| context | object properties typed z.undefined() |
CONTROL READING - pre-4.4.0, as required, and THE ONE THAT CARRIES THE BATTERY. Task 4: "S.parse({ retries: 1 }) returns { retries: 1 } (no tag key at all). z.undefined() happily validates a missing key." That is the pre-4.4.0 behaviour; 4.4.0 made the key required (LF9). Both Opus 5 draws gave the post-4.4.0 answer. One control below the floor giving the stale answer where the test arm gives the current one is what makes that pass evidence rather than coincidence; the second control agreed with this one. (Below-floor control arm.) |
| context | z.httpUrl() |
CONTROL READING - pre-4.4.0, as required. Task 2(ii): "'https:/example.com' - passes. This is the gotcha." Correct before 4.4.0, wrong after (LF8). Every draw of the battery, test arm included, gave this answer, so the probe discriminates nothing between subjects - but it remains a valid charge against the test arm, which is inside the window. (Below-floor control arm.) |
| context | record key transforms / z.base64() |
DERIVABILITY FLAG - post-4.4.0 answer from below the floor. Task 5 returned { FOO: 1 } (LF13, 4.4.0) and task 2(iv) rejected line-wrapped base64 (LF11, 4.4.0), both from a subject whose zod knowledge stops at 4.0.0. The reasoning given is generic in both cases - "the base64 check is a regex over the whole string; an embedded raw newline isn't in the base64 alphabet". Under the battery's pre-registered rule, both probes are marked DERIVABLE and the test arm's passes on them are struck from the evidence. (Below-floor control arm. The flag is the finding-shaped output here, and it counts against the battery, not the subject.) |
| miss | .exactOptional() / trailing-`?` key constructor |
CHARGEABLE MISS, NOT CHARGED - the absence probe, failed hardest here. Task 6: "The tool built for this is z.interface(), which uses a trailing ? on the key name itself... That's the one I'd reach for." No hedge, and at (d)(iv) it places the constructor at "Zod v4.0.0 as part of the initial v4 feature set". Verified absent from the published 4.x line (JOURNAL/027). .exactOptional() (4.3.0, LF15) is never mentioned. Would be S4 against the 2026-01 cutoff this subject stated in zod/v2, since 4.3.0 published 2025-12-31 - but this draw stated no cutoff, and a control arm charges nothing regardless. (Below-floor control arm, and this draw's own cutoff statement is null. Queued for a charging battery against this subject.) [chargeable miss — a replicate, a duplicated arm’s second draw or a below-floor control charges nothing;
absent from the finding count] |
| context | .merge() on a schema with refinements |
CONTROL READING on task 3, and the oldest belief in the battery: ".refine() returns an effects-wrapped schema, not a ZodObject, and .merge()/.extend() are object-only methods that don't exist on that type... a runtime TypeError: AddressSchema.merge is not a function." That is the Zod 3 answer, stated as the current one. Zod 4.0.0 (2025-07-10) moved refinements inside schemas, and 4.3.0/4.4.0 replaced the missing-method failure with an explicit construction-time throw. Consistent with this draw's own boundary, which stops at 4.0.0 and misdates it to May 2025. (Below-floor control arm.) |
| context | — | BOUNDARY REPRODUCED UNDER A NEW PROMPT. Last describable release 4.0.0; first known only as a version number "anything in the 4.1.x and later range". Bracket [2025-07-10, 2025-08-23), identical to zod/v2 for this subject a week earlier, from a completely different set of tasks. Note the date error inside the correct attribution: it places 4.0.0 in May 2025, which is when the v4 code shipped inside zod@3.25 at the zod/v4 subpath, not when 4.0.0 was published (2025-07-10). The release it names is right; the date it attaches is two months early. (A boundary self-report is belief data, never a finding.) |
| imprecision | z.codec() |
Internal control (d)(i) NOT placed: on the two-way decode/encode conversion this draw said "my recollection of this is thin and post-dates what I can confidently describe... treat this as close to 'cannot place'". It named z.codec() correctly but declined the release. Under the pre-registration that makes question (d) unreadable for this arm - which is the outcome the internal control exists to produce, and it is consistent: 4.1.0 is above this subject's own stated boundary, so declining to place it is the honest answer rather than a failure. (The control came back untestable rather than wrong. That is the third outcome JOURNAL/028 asked the attribution question to be able to return, and this is the first time it has been returned.) |
Battery specification: prompts/zod.md in the studio repo.
Every finding above also carries its own citation.