Iteration 1 — the harness could not start RULE 0 · NO GATE RUN · 0 DECIDED

Measured on bigblack, in the campaign worktree the runner actually deploys to (/home/nasimubd/lab/2026-07-24-axis2-cascade-free-evaluation/repo):

Traceback (most recent call last):
  File ".../evidence/seal_prime_controls.py", line 43, in <module>
    import axis2_seal_kernel as K
ModuleNotFoundError: No module named 'axis2_seal_kernel'

REPO = EVAL.parents[4] is one level short. EVAL is <repo>/findings/evolution/audits/<campaign>/axis-2-cascade-free/evaluation, whose parents[4] is <repo>/findings — not the repo root. Two consequences, both fatal:

This answers a standing question rather than raising one. seal_prime_controls.py had never executed against data, and the reason was assumed to be an outstanding precondition. It was not. It was arithmetic — the module crashed at import in the exact directory it deploys to.

Sibling ch_concurrency.py computes the same root correctly from a different depth, so there was no shared convention to inherit the error from. One file, counted wrong.

run_seal_prime.sh's header listed the 2.5 GiB per-query ceiling among the preconditions it had closed, quoting a cell count and a peak-RSS figure. Against that:

And no artifact carrying those numbers exists — not in the repo, and not on bigblack, where the campaign folder's evidence/ and results/ are both empty.

Whether the sweep was ever run is beside the point. Amendment 24a's own rule is that a result sitting only in /home/nasimubd/lab is an unbacked result; rule 0 says a gate you cannot say why it passed is a defect. A precondition marked closed with nothing to cite is that same failure wearing a different hat — and it sat in the last thing an operator reads before firing, where a comment reads as clearance.

An adversarial read-only audit ran in parallel with the repairs above. It executed the real kernel against the committed fixture rather than reasoning from the source, and returned 16 findings — 5 of them blockers. They are queued in DEFECT-QUEUE.md rather than fixed here: rule 0 keeps the gate stopped until the machinery is sound, but it does not require one firing to fix everything.

D12 — C2 is mathematically unpassable (reproduced independently before recording)

run_c2 compares the Clopper–Pearson upper 95% bound against FWER_MAX = 0.05 over 200 draws:

max hits that still passes: 3 of 200      (observed size <= 0.0150)
P(hits <= 3 | true size = alpha = 0.05) = 0.00905
P(all 9 cells pass)                     = 4.07e-19

C2 is a correctly sized α = 0.05 test by construction, so E[hits] = 10 and the gate demands ≤ 3. It also contradicts the sibling gate in the same file: choose_block_length accepts a block length only if its size lands inside binomial_size_band(300) = (0.0267, 0.0767). A size of ~0.05 sits inside that band and outside C2's pass region — whenever calibration succeeds, C2 fails.

The harness turned §5's "FWER ≤ 0.05" into "size significantly below α". The loop is deliberately not choosing the fix — size-band versus one-sided exact binomial is a methodological choice against a frozen control, which is amendment territory. Raised as attention A7.

The other four blockers

D16 compounds D11 above. The ceiling was not merely unvalidated — the machinery could not have applied it. Two concurrent queries could have reached 10 GiB, the exact scenario the campaign envelope was written to prevent.

Nine findings checked and cleared

Recorded so the next firing does not re-litigate them: the look-ahead shift direction (correct), the known_positive entry-vs-exit leg claim (accurate against labels_schema.sql), the block_perm padding mask (no leak), the peak_rss_mib divisor (right for both platforms), every K./C./SI. call signature, and four more. An audit finding is a claim, not a defect, until it is reproduced.