iter 4 — the guard measures line-proximity, not instability QUANTIFIED

Attack item R-6 · 2026-07-29 · harness harness/unanimity_false_veto.py · draft remedy PRE-REGISTRATION-DRAFT-xi-stability-guard.md

The rule under attack

A candidate passes the ξ stage only if xi_worst < 0.50 and zero of 62 cells is flagged unstable — a cell being unstable unless all 9 contiguous sub-slice readings agree on which side of the frozen lines the cell sits. In the instrument that is two lines:

if v == "PASS" and n_unstable > 0:
    v = "PENDING"          # rotation_robust_eval.py:555 (xi) and :670 (h_norm analogue)

Prediction, written before running

False-veto ≈ 0 at true ξ=0 (readings sit ~100 σ from the line), climbing steeply toward 100% as the true value approaches 0.50 — which would mean the guard measures proximity, not instability. Confirmed, and the transition is sharper than expected.

Result — 60 candidates per level, 62 cells, n=3,990, continuous x

Continuous x is deliberate: it removes the estimator's tie randomness entirely (iter 2), so everything below is the rule, not the estimator.

The load-bearing row is ξ=0.45. Worst-cell reads 0.4740 — below the line — and 72% are still refused, by the unanimity clause alone rather than by magnitude. Nothing is flagged at all up to ξ=0.40; then it collapses.

Attacking my own result

The 0.48 row overstates the case and I am not going to lean on it. Mean worst-cell there is 0.5046 — above the line. The statistic under test is a max over 62 cells, whose expectation exceeds the per-cell truth, so at ξ=0.48 those candidates are genuinely borderline at the worst-cell statistic and refusing them is defensible. The argument rests on 0.45; 0.48 is reported for shape only.

That inflation is itself worth recording: at ξ=0.45 the worst-cell mean sits +0.024 above the per-cell truth. That is the selection bias of a max-over-62 — the research's decision (b) — observed in this instrument rather than imported from a paper.

Why a flat tolerance k would not fix this

The obvious remedy is "allow up to k unstable cells", which is what the k-FWER route in the research implies. It fails here, because the failure is concentrated, not uniform:

Any fixed k large enough to recover power near the line nullifies the guard everywhere else. The required k is a steep function of proximity to the line — which is the formal statement that the guard is measuring nearness to a threshold rather than instability of the data. This refines the research's recommendation A3 rather than following it.

What did NOT change

No dial, band, threshold, tolerance or sub-slice fraction was touched, and the guard was not deleted — its strongest deletion argument is second-hand and about the sample mean, and ξ is not a sample mean (research gap #962). Four remedy options are drafted in PRE-REGISTRATION-DRAFT-xi-stability-guard.md, each with its free parameters named, awaiting operator sign-off. That is the whole of the loop's authority here.

Limits, stated rather than buried

• The rule is measured in isolation. Continuous x excludes estimator jitter by construction, so the interaction between a lattice-valued kernel's randomness (iter 3) and this guard is unmeasured.
• Synthetic cells are independent. The real 62 cells are strongly dependent — shared symbols, overlapping windows — which will change the joint distribution of the unstable count. The direction of that change is not established here.
• The 0.45 calibration targets a per-cell ξ, not a worst-cell ξ. The instrument adjudicates the max, so "true ξ" and "what the instrument tests" are not the same quantity, and the table reports both precisely for that reason.

Evidence: harness/unanimity_false_veto_evidence.json. Reproduce: VIRTUAL_ENV="" uv run --python 3.13 --no-project --with numpy --with pandas python3 harness/unanimity_false_veto.py