CHAIN_13 checkpoint — Block 1 diagnostics verdict and the Block-2 GO/NO-GO table

Date: Jun 12, 2026. What this is: the mid-chain user gate of CHAIN_13 (chain file). Five offline diagnostics ran against the 8 Phase 00 npz, each against bars recorded in tasks/chain13_criteria.md BEFORE any data. No full-helix lever run happens until you release it. Adversarially audited (6 verifier agents, one per section, Phase-00-verdict precedent): zero numerical errors; every rule application verified verbatim; one OVERREACH (the existence proof hardened into a universal) and four precision findings — all incorporated into this text.

Plain-language summary (read this even if you skip the rest)

The study’s levers came in expecting the schedule to be the villain. The diagnostics split the verdict by arm:

• The 6-DOF’s problem is geometry, as believed. A kinematics-only rollout of the demanded schedule reproduces its near-singular bands (5/5 logged peaks hit, all three speeds) — the demand itself drags the arm to the reach wall, and the run lives saturated there. The geometric lever (R, the standoff/reach corridor) is the only registered lever aimed at this, and it stays GO.
• The 7-DOF’s problem is NOT the schedule — it’s the route. The same oracle tracks the 7-DOF demand with median EE error 0.0000 m (max 0.566 m, a speed-invariant startup transient — the feedforward is zeroed at step 0) and predicts ZERO near-singular encounters at all three flown speeds — a wall-clear arm route EXISTS for the very schedules the live runs fall into potholes on. The walls are therefore not FORCED by the demand: the live system’s potholes are made by its own posture history (the null-space convention parks the ghost, it does not steer the posture; the freeze holds a basis, it does not move the arm off a wall) — the live policy demonstrably routes through walls that another policy avoids on the same demand. The ±2% “schedule sensitivity” is the route reshuffling (deterministic, non-monotone — “a lottery over routes” only as metaphor), not moving walls.
• Our own protection stack is acquitted at the peaks: inside the worst κ windows the Γ-Tikhonov-only band carries 0% of the error mass on all 8 runs, and the derate band at most 1.1% (one 2.2×-mass-over-time cell on r1 +2% — trivial magnitude, touches no registered rule); the windows sit in deep-damping/hold-last territory. The switch transients and the damping layers both failed to claim the registered error share — L4 and the directional-filtering follow-up do not fire.
• The thresholds now have a derivation: 0.025 is reproduced from the sim’s 50 rad/s budget with a √2 margin — “a numerics floor, not a hardware floor” — and the one misfit (the Γ floor 0.05) had its correction gated on a rule that did not fire, so nothing changes.

Verdict table (Block 1)

Supporting findings recorded outside the registered rules (observations, not verdicts): the 6-DOF crosses the 0.005 hard floor 11,891× on the nominal run (live chattering — the Holt & Desrochers regime; strengthens R’s case); r0’s cruise error is clean velocity lag (τ = 0.080 s, 5% residual) while r1’s is V-shaped in speed (36% residual) — L1’s premise is solid on the 6-DOF and insufficient on the 7-DOF; at the 7-DOF nominal’s peaks NO single geometric factor discriminates (reach −0.44 from D1; elbow −0.04 and wrist −0.16 from the committed CHAIN_10 tables, chain10_offline_tables.md §r1_7dof_path — same extractor, same windows) — a 6-DOF det-factorization probe is the wrong instrument for a 6×7 map.

D3 instrument disclosure (honest provenance)

The oracle’s first calibration run failed 0/8 with a constant 0.21 m tracking offset — an instrument bug (the feedforward demanded the goal’s WORLD rate while the COM transport already carries the EE; a P-servo on the unmodeled ~0.85 m/s leaves exactly 0.85/4 m). Fixed to the transport-relative rate; a per-rollout tracking-error witness column was added so the instrument’s tracking quality is inspectable next to its σ predictions (engagement-witness rule; report-only — no coded threshold gates on it). The pre-registered BAR was not touched. Probe scripts (validation/_oracle_probe*.py, untracked) are deletable debris.

Block-2 GO/NO-GO (rules quoted from tasks/chain13_criteria.md, applied verbatim)

Block 2 as adjudicated: r0 → R, L1, L3. r1 → L1 only. Each its own full-helix A/B with knob-OFF byte-identity (5 validators diff=0) and ±2% probes, per protocol.

Open questions at this checkpoint (your call — nothing proceeds without you)

1. Release Block 2 as adjudicated? (r0: R + L1 + L3; r1: L1.) Order suggestion: L1 first on both (one lever, both arms, same A/B harness), then R, then L3.
2. The posture-route lever (a NEW registration, if you want it): D3’s existence proof says a wall-clear 7-DOF route exists at every speed; the live v_n = 0 + freeze policy just doesn’t take it. A lever that steers the spare DOF along an oracle-supplied reference posture path would attack the actual mechanism — but it is NOT L2 as registered (different premise: route-tracking, not σ-gradient climbing), so running it requires a new amendment + criteria BEFORE any build. Note honestly: the oracle’s clean route is a kinematic existence proof; the live system also carries momentum dynamics and base-tracking error, so the achievable gap is the first thing a criteria file should bound.
3. L4 v2 rule? The registered rule measured switch-proximate mass INSIDE κ windows; thaws sit at window exits by construction, so the instrument under-counts them. The 83° thaw jump (CHAIN_6) remains a standing smoothness failure independent of this rule. If you want L4 re-adjudicated, a v2 rule (windows extended past thaw re-entry) needs registration first.
4. 6-DOF-only oracle re-registration? The oracle nailed every 6-DOF run (15/15 peaks) and failed every 7-DOF one — citing its stage-(b) grid for R’s design would be a post-hoc subgroup carve-out under the registered 8-run gate, so we don’t. If you want the oracle as R’s design instrument, a 6-DOF-only gate can be registered and the grid re-run cleanly (~30 min offline). Two latent deviations the audit found in the never-fired stage-(b) code must be fixed in that registration: certify() narrows candidate centers to radius_scale = 0.55 only (the registered grid is wider), and the per-run calibration bar silently adapts if a run has fewer than 5 peaks.

What this changes in the singularities study’s recommendations

§4.1’s “schedule layer = strongest leverage” survives only for the 6-DOF (geometric demand). For the 7-DOF, §4.2’s architecture layer (who carries the task / what the spare DOF does) is the live axis — but through route steering rather than the registered σ-gradient form. §4.3’s inversion-layer audit came back clean at the peaks (the stack is acquitted in-window); its remaining standing issue is the 83° thaw jump, which lives at window EXITS. CHAIN_10’s SEED verdict is refined: the schedule re-routes the arm’s configuration-space path, it does not move walls. Precisely stated (the audited form): no wall is FORCED by the demanded task path — at least one rate-feasible joint-space route (the oracle’s damped-inverse policy, kinematics-only, base exactly on guidance) tracks the same demand at every flown speed with σ₆ ≥ 0.05 throughout; the live v_n = 0 + freeze policy routes through walls on that same demand, avoidably.

regen: each linked report carries its own regen line; this verdict is curated by hand.