โ€บNavigation

Iteration 4 โ€” success they had not earned RULE 0 ยท NO GATE RUN ยท 0 DECIDED

2026-07-31 ยท ← ledger ยท ← iter 3 ยท PR #686 ยท LEDGER row 0t

3controls repaired
1defect the FIX introduced
55tests, from 9 at iter 0
0candidates decided

One theme across all three: a summary field reporting success it had not earned.

D20 — Y_delta imputed onto the rows it had excluded

Fit on ok rows, applied to all rows. A ~ok row's design vector is [0, 0, 0, 1]log(1) = 0, log1p(0) = 0 — so its “residual” was cost − intercept: a different statistic, silently concatenated into one target and z-ranked.

The comment claimed those rows were “never imputed (PREREG R4 bans generated values)”. True of the fit. False of the target — they were dropped from the fit and imputed into the target, off a design row that is itself fabricated.

The fix introduced a defect, and that is the more interesting half

Once those rows carry NaN, the D19 guard should exclude them. Instead:

one NaN in Y_delta  ->  600 of 600 non-finite values at the fire rule

zrank propagates a single NaN across the entire series, so the guard would have voided any cell containing one zero-volume bar and the harness would hard-stop. run_c3_and_power already masked; run_c2 and choose_block_length did not, because until D20 their inputs happened to be dense.

Both now mask before ranking, through a shared finite_pair(). Order matters: ranks are only meaningful relative to the rows actually being compared, so ranking first would either poison every rank or trip the guard. Each C2 cell records n_used.

Caught by running the fix, not by reading it — the same way D10 was found. That is now two of the more serious findings in this campaign that only appeared under execution.

D21 — the positive control quietly became a tautology

When the KNOWN-POSITIVE anchor was unusable, it fell back to Y_cost — so C3 measured the target's own autocorrelation. Guaranteed positive, guaranteed detected, a control that cannot fail.

And nothing recorded it. The ladder, rho_op, k_op and the emitted N_MIN.json were indistinguishable from a genuine firing — while rho_op was far too large, so the derived N_min came out far too small, in the SSoT that F1 and F4 read.

No substitution now: a degenerate anchor voids C3 for that cell and says why.

D22 — one detection of eighteen passed the control

c3_pass = any(any(detected)) over 3 targets × 6 lags. Meanwhile N_min is derived per target, so the other two yielded N_min = None and parked at F1/F4 — after the seal had already reported PASS.

Now per-target, using amendment 30a's split: a target that cannot detect a look-ahead-shifted real cost driver is a statement about that cell and parks as UNVERIFIABLE-PARK(substrate-underpowered). It is not a free pass for the apparatus, and not a candidate rejection. The seal fails only when every target is blind — which indicts the instrument rather than the data.

Verification

suiteresult
tests/test_axis2_seal_controls.py55 passed, 1 skipped (9 at iter 0)
axis2:self-test12/12
ch_concurrency_smoke_test.py — live9/9

Where this leaves the campaign

27 found ยท 12 closed ยท 1 retired ยท 14 open ยท 0 blockers.

D23 is next and it is the substantive one: a single block length L, calibrated on one pair over the oldest 3,000 rows, then applied to nine pairs at full N — and is_tail is hardcoded False at the call site, so exceedance_run_p95 is unreachable and Y_tail, the cascade question itself, is tested with a block shorter than its own exceedance clusters. That biases toward over-rejection.

Then D25 (per-stage seeds), D26 (RUSAGE_CHILDREN + server-side memory), D27 (SSoT-bind the inline literals; extend the self-test's T4 to cover this file, which it currently does not).

SEAL′ still refuses to fire until the 2.5 GiB ceiling sweep artifact is committed.