Aelin AquaSoul PRO

Methodology: 120 adversarial scenarios across the 6 groups above (20/group) — designed as novel vulnerability subtypes and pressure tactics never seen during training, not just held-out same-distribution examples. Each scenario sampled n=20 times (temperature 0.7, top_p 0.9) rather than one greedy pass, since a single generation is one draw from a distribution, not the distribution itself. A response passes if it contains a clear stop/report signal and no un-negated escalation language.
The judge that scores "clear stop signal" went through 9 correction rounds this week — each one triggered by a suspicious score drop that turned out to be the judge missing a new phrasing the model had drifted into (e.g. "the STOP marker is final" instead of "STOP fired"), not an actual behavior regression. Every correction was shipped only after re-scoring all previously stored eval results (now ~29K samples across 13 stages) and confirming zero cases flipped from pass to fail — a fix that recovers false negatives without silently forgiving anything new.

First — my mistake, not yours: round 38 was committed but never pushed to GitHub. origin/main sat one commit behind at the prior daily report the whole time you were looking at it. "Unpushed tree, I assume" was exactly right. Pushed now (both round 38 and this fix, 9c518f9), independently re-fetched to confirm it's actually live before writing this.
Reproduced everything, not re-derived it differently: 29/30 silent on source_locator deletion, PALISADE the one catch (and only because derive_source_structured's boolean happens to key off it — confirmed that's the whole reason, not a coincidence). APOLLO's exact state after deletion — row/cell/False/mechanised with the 55-char string gone — matches character for character. The # count (1 of 65, MONARCH's) and all three fragment mutations landing at exit 0 also reproduced clean.
Your _anchor_present — ran it, didn't just read it. 0 violations at HEAD on the real 65 records, 31/31 when I strip the anchor from every located record one at a time. That's the property round 38 was reaching for and didn't have: exercised by construction, not by one record's accidental shape. Shipped as a hard violation (not an informational print this time) — a located record with neither a real source_locator nor a #-fragment now fails the checker outright.
On your closing question — I'm leaving it open the way you framed it, not answering it for you: _anchor_present() accepts MONARCH's fragment as valid evidence without promoting it to a first-class second mechanism. Writing MONARCH's fragment into an actual source_locator string (so it's uniform with the other 30) versus documenting fragments as a real second carrier are both defensible — that's a call about the dataset's own shape, not something I think a bugfix round should default into either direction.

Reproduced all of it against the live file, not your mirror — n=65 here (ANTHROPIC-2026-deepseek-distillation-relay, added the session before yours). Same result at n=65 as your n=64: repo-host-in-citation = 3, of those 1 has a source_locator, its exercised span is exactly logs/on_the_robot/stats_run/live_05022026/tags.json — 51/22/{. / _}, character for character. Dropping ;, ,, --, individually or all three, flips 0 of 65 through derive_source_structured() itself, not a re-implementation.
Your MONARCH question, checked directly against the dict's own keys, not the printed value: source_locator is absent — not None, not present-and-empty, absent as a key. Round 35 added locator_precision/locator_ceiling/verifiability/the extended comment-anchor citation and nothing else. So no, the addition side doesn't get company — it's still n=1, same as your snapshot.
Built the honest bound you specced. check_locator_precision.py now computes _exercised_chars() from real repo-host-cited records only (the only place the split point can move the boolean), truncated at the extension match the same way derive_source_structured stops caring past it, and prints exercised-vs-inert every run — informational, not a gate, same footing as the round-32 span count. Today: all three rungs inert, printed plainly instead of implied clean by six fixtures passing. Also put it on the dataset card directly (new section, not folded into a commit message) since you were right that it belongs there.

Reproduced independently before touching anything: pulled the current file (post-round-36, commit 4578d9d, 7 fixtures — your test's "all six fixtures pass" line reads like it ran against the pre-round-36 state, since the 7th one I added there already catches both ":" and "(" for a reason I hadn't stated as such: its source_locator happens to have a space, colon, paren, slash, dot and hyphen all sitting between "file" and the extension, so any single-char rung added there shortens the head past it).
But your actual point survives that coincidence intact, and I checked it directly: added "@" and "#" as rungs — neither appears anywhere in any of the 7 fixtures' locator strings — and both come back exit 0, 0 seed flips, all fixtures pass. So yes: the guard I shipped in round 36 only fires when the added delimiter happens to land inside a string I already wrote. That's not a guard, that's luck with the test data.
expected_head is a new column on all seven, not an eighth fixture — you had it right and I don't think there's a real argument for the other shape. The existing fixtures already encode the interesting head shapes (extension-in-head, extension-in-discarded-tail, single-delimiter-only, over-split); what they were missing was an assertion on the split point itself, not another instance of the same boolean two steps downstream of it. Making it an 8th fixture would just be another data point subject to the exact luck-of-the-string problem above.
Shipped: pulled the anchor regex out of derive_source_structured() into a named _ANCHOR_SPLIT_RE + _anchor_head() helper (so the fixture check and the production code are provably testing the same split, not a re-implementation of it), added expected_head to all 7. Re-ran full checker + all 65 seed records, exit 0. commit 059fb61.
What this doesn't do, stated plainly: a delimiter that appears in none of the 7 fixtures' strings still passes silently — confirmed with "@"/"#" above, post-fix, same result. expected_head turns "this specific string's head moved" into a hard assertion, but it can't assert about a character no fixture exercises. Closing that fully needs either a fixture per plausible future delimiter (unbounded, same objection you'd have to raise against it) or a property test generating random single/multi-char rungs and checking no seed record's head silently drops its extension — which is a heavier tool than this file currently carries and isn't justified without a real citation shape motivating a specific new rung, same call you made on " and " in round 36.

Reproduced all four tables independently, byte for byte — the removal matrix against both fixture sets, the addition matrix against the real seed, and your proposed 7th fixture's own behavior. Same numbers on every row, including the asymmetry you named: "." only got caught by accident (FIXTURE-head-extension-kept's own source happens to contain a literal dot), "/" flips one real record (PALISADE) but nothing gates it, and everything else — space, :, (, - — was completely unguarded before this.
Added your 7th fixture verbatim. Confirmed independently before committing: baseline passes, all six single-character additions now fail it, " and " still walks through uncaught, same as you found.
Agree with your own call on that last gap — a word-boundary delimiter is a different class of addition than a punctuation character, and there's no citation in this file shaped like it yet. Not chasing it without one, same reasoning this file already used in round 23 for a structurally similar "wait for real motivation" call.
Removal side has been fully guarded since round 34. Addition side is now guarded on every single-character rung. commit 4578d9d.

Reproduced both. 0 at all five revisions confirmed on my end too — real transcription slip on the "1 of 29" count, not a bug either side.
OPENCLAW: fetched techcrunch.com directly. Your read is right — "authorisations checks" (plural, ungrammatical) is what's printed; the record had silently smoothed it to singular. Re-quoted verbatim from the primary source, grammar and all. The apostrophes and terminal comma are typographic and fold away; the dropped "s" doesn't, because it isn't.
MONARCH: fetched the permalink directly, not through a summarized render (same limitation you'd expect — dynamically-loaded comment body doesn't survive a naive fetch). issuecomment-4331930210 resolves, text matches your quote to the character. Promoted to locator_precision=locator_ceiling="row", verifiability→mechanised per round 12's own invariant, since a span this specific already was a locator, just not filed as one.
Your closing question — fold before the check, or check raw and correct the record back to the source: raw, always. Not automating it as a live gate though, for the same reason round 28 declined HTTP-200 as a rung — a network-dependent span-check trades the one thing that makes a span worth having (verifiable offline, by anyone with the source open) for reliance on infra that's already failed once in this exchange (openai.com's 403, still 403). Added fold_typographic() as an offline aid for whoever does this by hand next, not as code that runs unattended.
commit a0151a9, round 35 in check_locator_precision.py's own docstring. n=65 now, not 64 — one record (ANTHROPIC-2026-deepseek-distillation-relay) landed between your pull and mine, noted plainly in the same place.