Pick Up the Pieces — catching up on June 12, 2026

Status report written June 13. Source documents are linked inline. Every metric is decoded in the Legend; every verdict cites the file it came from.

TL;DR (read this first)

Yesterday was four chains plus the round-1 shootout closeout. In one breath:

• Phase 00 picked a winner. The already-adopted 6-DOF path controller (r0) is the robust winner of the four-architecture shootout — the only configuration that passes all three gates and keeps passing them under ±2% speed. The 7-DOF (r1) is faster and covers more, but it fails the position-error gate at every speed. See phase00_round1_verdict.md.
• CHAIN_10 explained the scary number. A ±2% cruise-speed change swings 7-DOF near-singular dwell wildly (431 s → 3 s). Forensics cleared numerics and target curvature; the mechanism is the schedule moving which orbit phase the arm hits its reach limit at, amplified by a seed-sensitive pothole entry rate. See chain10_kappa_forensics_verdict.md.
• CHAIN_11 + CHAIN_12 cleaned house. Purged 15 dead config keys, unified the geometry layer onto utils/mesh.py, and retired the losing reactive guidance machine (−181 lines) — all proven behavior-preserving (every baseline byte-identical, zero re-pins). See CHAIN_11.md and CHAIN_12.md.
• CHAIN_13 diagnosed, then pulled levers. Five offline diagnostics, then lever runs. The headline: the reach-corridor lever at radius_scale 0.40 dominates the 6-DOF incumbent (29% faster, pe_p99 −4%, ze_p99 −10%) and is robust under ±2%. Two other levers (L1 velocity-FF v1, L4 thaw) came back falsified / NO-GO. See chain13_r_verdict.md and chain13_diagnostics_verdict.md.

The one decision on the critical path: do you adopt the reach corridor rs 0.40 (which triggers a re-pin of all five baselines), keep the incumbent, or go straight to the phase-varying “R-v2” idea? Everything downstream — including the 46-run fragility campaign baseline — waits on that. Details in § What needs your input.

Legend — runs, metrics, shorthand

The four shootout configs (architecture under test, not tuning):

Metrics (all reported at the 99th percentile unless noted; p99 = “worst 1% of steps,” the committee-relevant tail):

Shorthand: Cliff’s δ = a non-parametric effect size (|δ| ≥ 0.5 = “large,” the pre-registered bar). Levers L1–L4, S, R = candidate round-2 interventions. EVENT vs BROADBAND = whether error concentrates at conditioning spikes or is spread out. Re-pin = the deliberate, recorded act of replacing the frozen baseline logs after an adopted behavior change.

The arc of the day

The work followed a deliberate order — measure → explain → clean → intervene:

1. Phase 00 (overnight → afternoon): a pre-registered shootout of the four architectures over the full 30-rev pole-to-pole helix, then a ±2% speed sensitivity probe on the top two. Outcome: r0 wins robustly; r1 loses on position error but wins everything else.
2. CHAIN_10 (early AM): offline forensics — why does ±2% speed swing singularities so violently? — using only the eight logged runs, no new simulation.
3. CHAIN_11 (Chain A of the deep clean): clean the center-of-mass side, adopt the documented mesh layer, prove it generalizes to two new target satellites.
4. CHAIN_12 (Chain B of the deep clean): retire the reactive guidance machine entirely.
5. CHAIN_13 (Phase 00 round 2): “audit-before-adding” — five offline diagnostics, a checkpoint, then lever runs.

Step by step

1. Phase 00 — the configuration shootout

Goal: with no per-config tuning, which of the four architectures wins over the full mission, and is the winner robust to a small schedule perturbation? The rules — ranking order, fragility definition, stretch targets — were pre-registered in phase00_protocol.md before any run.

What happened:

• The four nominal-speed runs scored (phase00_round1_table.txt): r0 passes 3/3 gates (pe_p99 0.1651); r1, r2, r3 each pass only 2/3. The 7-DOF family wins coverage (all 1.0000), completion, and every conditioning metric; r0 wins the gate discriminator pe_p99, pointing (ze_p99 0.0549 vs 0.86–1.79), and smoothness.
• The ±2% speed probe on the top two (phase00_round1_with_probe_table.txt): all three r0 variants keep 3/3 gates; all three r1 variants fail the pe gate (0.2294 / 0.2804 / 0.3092). The 7-DOF dwell cliff appears here — r1 dwell nominal/−2%/+2% = 430.9 / 231.0 / 3.27 s, wildly non-monotone.
• The verdict (phase00_round1_verdict.md) declared r0 the robust winner (fragility rule does not fire), r1 the runner-up, r3 third, r2 worst. A provenance check confirmed r0 reproduces the adopted Mission-1 headline to three digits (pe 0.1651 vs 0.1654) — the harness is faithful.

Mechanism story: r0’s conditioning is structurally saturated (throttled ~64%, dwell ~630 s at every speed) — that saturation is why ±2% can’t worsen it, at the cost of slow completion (~1071 s). r1 is marginal and event-driven, hence the cliff. The dwell cliff and non-monotonicity were handed to CHAIN_10.

Two amendments you signed off (recorded in phase00_protocol.md): - Amendment 1: lever L1 (velocity-lag feedforward) applies to both r0 and r1, with a pre-committed bar — an L1-hardened r1 only outranks r0 if its pe_p99 drops below 0.1651 (not merely below the 0.20 gate). - Amendment 2: two new levers join — S (schedule re-timing, 7-DOF) and R (reach corridor, 6-DOF) — and scoring splits per arm. Round 2 executes as CHAIN_13: diagnostics first, lever runs gated on criteria and your explicit release.

The remaining open items were collected for you in round_2_questions.md.

2. CHAIN_10 — why ±2% speed swings singularities (κ forensics)

Goal: explain the dwell cliff using only the eight existing logs — zero new simulation. Four hypotheses (H1 finite-difference numerics, H2 target curvature, H3 reach-phase alignment, H4 dwell amplifier) and their kill/confirm thresholds were pre-registered in chain10_criteria.md before any peak was extracted. The design and plan are in chain10_kappa_forensics_design.md and chain10_kappa_forensics_plan.md; the chain log is CHAIN_10.md.

What happened (verdicts in chain10_kappa_forensics_verdict.md, raw tables in chain10_offline_tables.md):

• First, a verified foundation: the offline κ replay matched the controller’s logged values to exactly 0.0 relative difference on all eight runs — so every conclusion rests on a bitwise-faithful instrument.
• H1 (numerics) — KILLED by a two-command code audit (chain10_codepath_audit.md): the finite-differenced tangent is computed but its only consumer discards it (_), and the ff_route knob that promised consumers is a dead config key. Inert in all configs.
• H2 (target curvature) — KILLED offline: curvature at κ peaks is indistinguishable from, or lower than, calm windows on every run.
• H4 (dwell amplifier) — SEED verdict: pothole entry count swings 23 / 14 / 2 (a >10× swing, far past the 2× bar) while episode length collapses. The dwell loop lengthens episodes; it does not cause the ±2% sensitivity.
• H3 (reach-phase) — UNRESOLVED as registered, but the leading survivor: the crude reach_b driver missed (reported honestly, no goalpost moved), yet the κ hot band physically moves with the schedule for the 7-DOF (peaks shift from phase 0.29–0.35 at −2% to entirely in the startup band 0.014–0.065 at +2%), while the 6-DOF bands don’t move at all.
• Bonus that matters for your theory paper: the 7-DOF pointing error is EVENT-dominant (concentrated at κ peaks, δ up to 0.94 on the dwell-free +2% run), not broadband. Implication: scrutinize the near-singular freeze/derate handling in derivation_7dof.md before suspecting the reconstruction math.

One-sentence mechanism: a ±2% timetable change moves which orbit-phase band the arm traverses near its extension limit; the marginal 7-DOF’s pothole entry rate swings by orders of magnitude while the saturated 6-DOF barely notices.

3. CHAIN_11 — deep clean, Chain A (COM core + mesh)

Goal: clean the center-of-mass side of the stack so dead signals can’t burn investigation time again, adopt the documented utils/mesh.py geometry layer, and prove the cleaned stack works on satellite meshes it has never flown — without touching EE planning. Criteria pre-registered in chain11_criteria.md; chain log CHAIN_11.md.

What happened:

• A config-flag audit (config_flag_audit.md) classified the surface: 76 LIVE / 4 validation-only / 14 dormant / 18 dead. Crucially, §6 re-verified every “DEAD” verdict before deletion and found 4 of 20 were WRONG — including the live kernel-freeze knob. Verify-before-delete is now standing policy.
• A1 removed 15 verified-dead keys; A2 removed a dead arclength function (which also computed closed-path length for an open helix — wrong if ever called); A3 adopted utils/mesh.py and deleted OrbitSurfacePath / orbit_path.py. Every step held to bit-identity (6 validators at diff = 0, scoreboard byte-identical).
• A4 (surface_path_continuity.md): all three meshes (GRO, RCM, AcrimSat) pass every continuity bar; RCM and AcrimSat are cleaner than GRO. A useful finding — the rate limiter saturates exactly at max_step, so it’s load-bearing (smoothing alone doesn’t bound the step).
• A6: both new targets flew short COM flights at κ p50 ≈ 78, matching GRO cruise.
• A7 — the σ-signal study (sming_vs_sminj_study.md): s_min_J is REDUNDANT with the live driver s_min_G (Spearman ≥ 0.997, derate agreement 1.0000). Key inversion: s_min_G was the live driver all along; the J-side was bookkeeping, slated to retire into Chain B’s single re-pin.

Still open inside CHAIN_11: task A5 (a --target {GRO,RCM,acrim} knob on run_mission.py) is unchecked.

4. CHAIN_12 — deep clean, Chain B (retire the reactive machine)

Goal: remove the losing reactive guidance architecture so the system tells one targeting story. You signed off the casualty list (“Commence the housecleaning!”). Criteria pre-registered in chain12_criteria.md; chain log CHAIN_12.md.

What happened:

• B1 — the kill: reactive branch and casualties removed, net −181 lines. The load_parameters canary caught a derived lookahead consumer that both audits had missed (a real lesson: derived-parameter plumbing is a blind spot for leaf-name config sweeps).
• B2 — finder unification: the EE target finder now shares the one utils/mesh.Mesh (paying off CHAIN_11’s double-load debt), keeping the query trees bit-identical. The faster cKDTree swap was deliberately deferred and left severable.
• B3 — the proof: both full-helix missions — pose (r0) and anchor (r3) — replay byte-identically against their Phase 00 logs (every array, every key). The retirement was behavior-preserving.
• B4 — closeout: established high_level_plans/pre_risk.md as the consolidated living pre-risk source of truth.
• Zero baseline re-pins, exactly as pre-registered. Validator count is now five (base, ee_initial, ee_targeting, ee_tracking, ee_coverage).

5. CHAIN_13 — Phase 00 round 2: diagnose, then pull levers

This was the evening’s big effort, and the one your memory checkpoint pointed at. Its philosophy: audit before adding. Criteria pre-registered in chain13_criteria.md; chain log CHAIN_13.md.

Block 1 — five offline diagnostics (D1–D5)

First, a harness verification (harness.md) confirmed what the logs do and don’t contain — notably that freeze and hold-last steps are not offline-reconstructible (they depend on stateful caches), while speed and radius_scale are plain sweepable overrides. It also flagged a missing tool: there’s no IK-only joint-path generator producing an offline q_des(s) independent of dynamics.

The diagnostics, scored against bars written before any data, and summarized in the checkpoint chain13_diagnostics_verdict.md:

• D1 (H3 closure) — H3 OPEN (2/8 at the bar). On the redundant 7-DOF arm, no single geometric factor discriminates the peaks. Details in chain13_h3_closure.md.
• D2 (attribution audit) — the mitigation stack is acquitted at the peaks: the Γ-Tikhonov band carries 0.0% of in-window error on every run; derate at most 1.1%. The errors live in deep-damping / hold-last territory. The lag/event split gives r0 a clean velocity-lag time constant (τ = 0.080 s) but r1 a messy one (τ = 0.164 s, 36% residual) — so L1’s premise is solid on 6-DOF, insufficient on 7-DOF. Full audit in chain13_attribution.md.
• D3 (schedule-κ oracle) — the headline diagnostic. Calibration failed 3/8, split exactly by arm: the 6-DOF passed all runs (its bands are demand-geometric — the schedule itself drags the arm to the reach wall), the 7-DOF failed all runs (a wall-clear joint route provably exists at every flown speed, but the live v_n=0 + freeze policy doesn’t take it — the potholes are route/policy-made, not schedule-made). An instrument bug (a transport double-count causing a constant 0.21 m offset) was found and fixed before the verdict, bar untouched. Detail in chain13_schedule_oracle.md. This refines CHAIN_10’s SEED verdict: the ±2% “sensitivity” is the route deterministically reshuffling, not moving walls.
• D4 (threshold re-derivation) — PASS: the 0.025 derate floor is a numerics floor (from the sim’s 50 rad/s clip with a √2 margin), not a hardware floor. Deliverable: threshold_derivation.md.
• D5 (H_norm pilot) — KEEP as offline-only (boundary 6/8, r3 exactly at the bar with zero margin). hnorm_pilot.md.

The checkpoint was adversarially audited by 6 verifier agents (one per section): 0 numerical errors, 1 overreach (an existence proof had been hardened into a universal claim) + 4 precision fixes, all incorporated. It adjudicated Block 2 as r0 → R + L1 + L3 and r1 → L1 only, then stopped: AWAITING USER RELEASE.

A companion math deliverable, posture_proof.md, lays out three pre-registrable, offline-computable bounds (U1 admissibility, U2 Weyl margin consumption, U3 fiber-coordinate reachability) for the oracle-gap question — delivered but not yet computed/adjudicated.

Block 2 — the lever runs (after release)

• R (reach corridor, 6-DOF) — the win. Values 0.50/0.45/0.40 were registered before the runs (relief direction down: the default rs 0.55 already rides ~96% extension). Verdict in chain13_r_verdict.md:
  • rs 0.45 FAILS (derate 0.644 → 0.766). The 200 s screen that showed 0.000 was a southern-cap artifact — reach demand varies pole-to-pole, so a static corridor only trades bands.
  • rs 0.40 PASSES all bars and DOMINATES the incumbent: completion 1070.8 → 762.6 s (−29%), pe_p99 0.1651 → 0.1586 (−4%), ze_p99 0.0549 → 0.0495 (−10%), absolute derated time −32%, coverage 0.9978. ±2% probes pass → ROBUST (pe_p99 flat at 0.158 vs the incumbent’s 0.165–0.170).
  • Honest cost: median pe rises 0.071 → 0.102 m because the vehicle stops crawling — but the p99 gate metric is what improved.
• L1 (velocity-lag FF) v1 — FALSIFIED (chain13_l1_design_probes.md): the Coriolis-referencing design made cruise pe 2.7× worse (0.075 → 0.200 m) because the referenced term re-energizes the loop past the derate. Decomposition showed the arm acceleration feedforward dominates the floored-regime RHS ~4× over stiffness — so that, not Coriolis, is the real lag owner and the L1-v2 target. The knob stays default-OFF (byte-identical); full helix withheld pending a v2.
• L4 (kernel-freeze thaw) v2 — NO-GO (chain13_l4v2.md): thaw transients are real but the event-centered bar is met on only 2/5 7-DOF runs (bar ≥ 3/5). The 83° thaw jump remains a standing smoothness failure at window exits.

A PEBKAC note from the day: run_mission was dying at the npz save line on a missing parent directory — two 27-minute sims lost before it was fixed (it now creates the directory).

What worked

• The shootout produced a clean, defensible winner with a mechanism story, not just a number — and the winner reproduces the adopted headline to three digits.
• The deep clean was genuinely behavior-preserving: −181 lines plus 15+ dead keys removed, and every surviving baseline stayed byte-identical. Zero re-pins.
• Verify-before-delete paid off twice: 4 false “DEAD” verdicts caught in CHAIN_11, and a hidden lookahead consumer caught by the loader canary in CHAIN_12 that both audits had missed.
• D3’s oracle is the strongest scientific result of the day: it cleanly separates the two arms’ singularity mechanisms (6-DOF demand-geometric vs 7-DOF route/policy-made) and provides an existence proof of a wall-clear 7-DOF route — which reframes the whole 7-DOF mitigation question.
• The reach corridor rs 0.40 dominates the incumbent and is robust — a real, adoptable improvement that arrived with its honest cost (median error up) disclosed.
• Process discipline held throughout: pre-registered bars, honest reporting of misses (H3’s reach_b), an instrument bug fixed before its verdict, and a 6-agent adversarial audit of the checkpoint.

What didn’t work

• The 7-DOF (r1) cannot meet the position-error gate at any speed — its advantages (coverage, speed, conditioning) don’t rescue the gate metric.
• Three of the round-2 levers came back empty: L1-v1 falsified, L4-v2 NO-GO, lever S (schedule re-timing) NO-GO (its oracle gate failed on the 7-DOF). The static reach corridor at rs 0.45 also failed.
• H3 stays OPEN — on a redundant 6×7 map, a 6-DOF-style geometric factorization is the wrong instrument; the right discriminator is still unknown.
• The “switch to a κ headline” rule did not confirm (it tripped only the κ-p50 gate), so the derate-fraction headline stays — reported with schedule context.

What needs your input (decisions + alternatives)

Ordered by how much they gate other work. The first is on the critical path.

Decision 1 — Adopt the reach corridor rs 0.40? (critical path)

rs 0.40 dominates the incumbent and is robust under ±2%. Adoption triggers the §3b re-pin ceremony (one deliberate re-pin of all five baselines, recorded decision, double reproduction, ground-rule update). This also sets the baseline the fragility campaign will measure. Source: chain13_r_verdict.md. - (a) Adopt rs 0.40 → run the §3b re-pin; rs 0.40 becomes the frozen-baseline candidate. - (b) Keep the incumbent rs 0.55; the verdict stays on record. - (c) Skip the static corridor and go to R-v2 (a phase-varying corridor, designed offline by the parked 6-DOF oracle) — the motivated successor, since reach demand varies pole-to-pole.

Decision 2 — What’s next on the levers (the rest of Block 2)?

Block 2 was adjudicated r0 → R+L1+L3 and r1 → L1 only. R is done (Decision 1). L1-v1 is falsified → needs an L1-v2 redesign targeting the acceleration feedforward. L3 (pointing retune, GO) hasn’t run yet. Sources: chain13_diagnostics_verdict.md, chain13_l1_design_probes.md. - (a) Queue L1-v2 + L3 next (note: L1-v2 likely waits behind the rs 0.40 adoption, since v1 showed inversion/FF tweaks don’t act cleanly while the arm rides the reach floor). - (b) Run L3 alone now; defer L1-v2. - (c) Hold all levers until Decision 1 settles.

Decision 3 — Authorize a new posture-route lever for the 7-DOF?

D3 proved a wall-clear 7-DOF route exists. A lever steering the spare DOF along an oracle-supplied reference posture would attack the actual mechanism — but it is not L2 as registered (route-tracking, not σ-gradient climbing), so it needs a new amendment + criteria first, and the criteria must bound the gap between the oracle’s clean kinematic route and the live system (which carries momentum dynamics). Source: chain13_diagnostics_verdict.md. - (a) Authorize the amendment + criteria, then build it. - (b) Decline — leave the 7-DOF route mechanism unaddressed this chain.

Decision 4 — Re-register the 6-DOF oracle (unlocks R-v2)?

The oracle nailed all 6-DOF runs (15/15) and failed all 7-DOF. Citing its stage-(b) grid now would be a post-hoc subgroup carve-out. A clean 6-DOF-only gate (~30 min offline) would legitimize it as R’s design instrument — but two latent stage-(b) code bugs must be fixed first. Source: chain13_diagnostics_verdict.md. - (a) Register the 6-DOF-only gate (fix the two bugs, re-run the grid). - (b) Leave the oracle parked as the R-v2 idea only.

Decision 5 — Accept L4 NO-GO, or push a further v2?

L4-v2 came back NO-GO (2/5). The 83° thaw jump is still a standing smoothness failure. Any further look needs windows extended past thaw re-entry, registered first. Source: chain13_l4v2.md. - (a) Accept NO-GO; leave L4 out. - (b) Register a further v2 (extended windows) and re-adjudicate.

Decision 6 — Envelope provenance (committee-facing soft spot)

Decide and document what the engineered joint envelope is. The original XML box_limited ranges are task artifacts, not UR3 spec; the engineered envelope is data-derived (healthy-regime support + sin(θ₃) fences). Source: open_questions.md §B. - (a) Mission spec · (b) Datasheet-derived · (c) Engineered (data-derived).

Decision 7 — Fragility campaign baseline + release

Before the 46-run Phase 0 fragility campaign (1 nominal + 3 sources × 3 magnitudes × 5 seeds), the frozen baseline must be re-pinned to the Phase 00 winner and E2’s nominal numbers updated. Suggested release order: nominal cell first (wall-time check), then per-source. Sources: fragility_criteria.md, round_2_questions.md §3. - (a) Re-pin to the Decision-1 winner, then release nominal → per-source. - (b) Hold the campaign until the lever picture (Decisions 1–2) fully settles.

Quick ones (minutes each)

• Roadmap home: tasks/cleaner.md was deleted; which file is the living roadmap? CHAIN_12 established pre_risk.md as the consolidated pre-risk source of truth — likely this is the answer; please confirm (vs master_plan.md). Source: round_2_questions.md §5.
• wrist_2 (sin θ₅) fence is unused in logged data — cut it formally, or document as decorative? (open_questions.md §B)
• Mesh prototype wire-in — listed as pending in open_questions.md §D, but CHAIN_11 (A3) and CHAIN_12 (B2) appear to have already done this; please confirm it can be closed.
• CHAIN_10 T6 geometry falsifier (RCM/AcrimSat full-helix) — now optional since H2 was killed offline. Release / skip / defer? (CHAIN_10.md)

What needs more study (no decision required yet)

• L1-v2 design: re-target the arm acceleration feedforward (M·ν̇_des, an FD-of-FD at dt=0.03) — it dominates the floored-regime RHS 4× and is a noise-dither suspect. It sits on the already-registered desired-twist path. (chain13_l1_design_probes.md)
• R-v2 (phase-varying corridor): the natural successor to rs 0.40, designed by the parked 6-DOF oracle’s speed × standoff grid. (chain13_r_verdict.md)
• The posture_proof.md bounds (U1/U2/U3) are delivered and offline-computable but not yet computed/adjudicated. (posture_proof.md)
• H3’s true discriminator for the redundant arm — a 6-DOF det-factorization is the wrong instrument for a 6×7 map. (chain13_h3_closure.md)
• H3 follow-up in CHAIN_10: swap the crude reach_b proxy for the true extension margin / strided s_min_G replay (a minutes-long offline re-run of the committed harness). (chain10_kappa_forensics_verdict.md)
• Theory gaps from the pre-risk ledger (open_questions.md §C): P1 the M̆/C̆ basis inconsistency (1.9% median, ~100% in derated tails); P4 the null-space damping ISS proof is only a sketch; and the analytical joint-envelope derivation from det(J)=R(θ)·sin θ₃·sin θ₅ (the hard part is the reach/shoulder factor R(θ)) — your theory track.
• 7-DOF envelope re-derivation on 7-joint data: the elbow now rides its fence 20–30% of steps (vs 0.000 at adoption). (open_questions.md §B)
• CHAIN_6 κ-p50 bookkeeping (recorded “+42%” vs arithmetic “+49%”) — low-priority correction, blocked only on legacy log key layout. (chain10_kappa_forensics_verdict.md)
• Idea seeds (ideas.md): track κ(J) and Yoshikawa manipulability instead of homebrewed s_min signals; the free-flying-singularities research question; the “BRUSCHI” reference to chase.

Appendix — where everything lives

Chain narratives (tasks/daily_log/Jun12_26/): CHAIN_10.md · CHAIN_11.md · CHAIN_12.md · CHAIN_13.md

Pre-registered criteria (tasks/): chain10_criteria.md · chain11_criteria.md · chain12_criteria.md · chain13_criteria.md · fragility_criteria.md · phase00_protocol.md

Evidence reports (generated_reports/GNC/Jun12_26/): phase00_round1_verdict.md · chain10_codepath_audit.md · chain10_kappa_forensics_verdict.md · config_flag_audit.md · sming_vs_sminj_study.md · surface_path_continuity.md · harness.md · chain13_diagnostics_verdict.md · chain13_attribution.md · chain13_schedule_oracle.md · chain13_h3_closure.md · chain13_r_verdict.md · chain13_l1_design_probes.md · chain13_l4v2.md · hnorm_pilot.md

Math deliverables (generated_reports/math/): threshold_derivation.md · posture_proof.md

Living state: pre_risk.md (consolidated pre-risk source of truth) · open_questions.md (pre-risk ledger) · ONGOING.md · PIN_IT_FOR_LATER.md · ideas.md