RWG-1 — the runaway-order guard: phantom turnover-blend base on a HALT, and a blocked drawdown liquidation

status: open · raised panel run 11 (2026-08-20) · migrated 2026-08-24 (body verbatim below) · class: loudness & safety (live path) · judgement: YES · effort ~0.5–1 pd · leg 1 was resolved by the owner 2026-08-20 — see the dated triage note at the foot

15. RWG-1 — the runaway-order guard has halted the meanrev control sleeve two consecutive days (zero orders; the sell-count floor rose 44→149), the halt path advances its own turnover-blend base while nothing executes (unruled semantics), and a drawdown kill-switch liquidation of the current 196-name book would be blocked by the same guard — armed today, not latent. · judgement: YES · effort ~0.5–1 pd · horizon: live now (the control is not trading; the phantom blend base compounds each halted day)

Ground truth (data/state/meanrev/order_log.jsonl): 08-19 safety_halted: true, "205 orders exceeds max 150 (runaway guard)", n_targets 209, n_submitted 0; 08-20 same at 158 > 150, n_targets 161, n_submitted 0; selection_completed: false both days; equity marks continue on a frozen book (196 names, portfolio_snapshots 08-17→08-20: 173→185→196→196).

Leg 1 — calibration is a policy call, and it is the owner's. The guard counts the entire batch with no de-risking exemption (safety.py:245-250); the only de-risking exemption in the file (all_de_risking, safety.py:225) gates the daily-loss breaker alone — so CLAUDE.md's "de-risking is never blocked" is true only there and for per-order REJECTs. config/meanrev.yaml:128 pins max_orders_per_run: 150 as a bare copied value; the calibration comment behind 150 ("a full rebuild is ~50-100 orders") lives in momentum's config (settings.yaml:238) — a 50-name-sleeve number applied unmodified to a daily-churn sleeve holding 196 names against a 50-name selection (PC-1's unbounded growth, peak 2.92x). Options, none pre-decided: (a) exempt all-sell batches from the count guard (the guard's Knight-Capital rationale is amplification, mostly buy-side — but a runaway-sell loop is a real class; this trades that protection for guaranteed de-risking); (b) scale meanrev's max_orders_per_run to its book (config VALUE — owner-only, the panel proposes nothing here); (c) accept the wedge for the never-promotable control and record that it trades only on sub-150-order days. Every code path here is the fail-closed safety layer: the panel does not touch it.

Leg 2 — the blend base advanced while nothing executed; rule the semantics before the burst arrives. daily.py:1623-1634 persists last_targets (the next day's turnover-blend base) before execute_orders (:1692), guarded only by dry_run — no halt guard. Verified consequence: kelly_ledger.json last_targets is dated 2026-08-20 with 161 weights despite zero submissions, and weighted_turnover read exactly 0.5000 = the cap on both halted days — measured against the phantom base, so the intended book has walked two full cap-steps away from the real one; the clearing day's realized weighted churn against the REAL book can approach ~1.0, far past the daily cap. (The 205→158 order-count decline is phantom-target decay, not book convergence — sells rose 44→149 while resizes shrank.) This is a semantics divergence to rule, not a plain bug: the engine's own nearest analog retains the intended book in-cash and re-enters uncapped (engine.py:868-873, :657-666), and the live comment shows deliberate mimicry — but a safety HALT was unmodeled. Either gate the persist on execution success, or record intended-book semantics (and the post-halt burst) as deliberate; pin whichever ruling the owner records with a test.

Leg 3 — the same guard blocks the emergency exit, and on meanrev it is armed now. The drawdown kill-switch flat-to-cash path (daily.py:1089-1105) routes through pipeline.execute_orders → _safety_gate → the count guard, which exempts nothing: a liquidation of any >150-name book HALTs. For meanrev's current 196-name book this is not latent — its own kill switch firing today would be blocked (momentum at 63 names is clear). This contradicts the safety layer's own stated intent ("blocking a de-risking trade during a crash would leave the book exposed, the opposite of fail-closed", safety.py:216-219) precisely in the emergency it exists for. Compounding, same persist-before-execute class: the kill-switch path wipes the Kelly holding-return snapshot at daily.py:1101-1103 before execute_orders — a halted liquidation clears the snapshot while the book remains fully held. Legs 2+3 resolve in the same fix-sitting as leg 1's policy call.

Test design. Leg 1 (if (a)): a 196-sell batch passes the count guard, a 196-mixed batch still halts; revert → red; regression: a simulated kill-switch liquidation of a >150-name book reaches the broker. Leg 2: pin the recorded ruling (halt → last_targets unmoved, or intended-book semantics asserted with the burst documented); revert → red. Leg 3's snapshot wipe: on a halted liquidation, the Kelly snapshot survives.

Kill criterion — pre-registered. If by 2026-09-04 (10 td) meanrev has resumed submitting with NO config or code change, the wedge-persistence claim for this instance is falsified — record that, and the row narrows to legs 2+3, which stand independently of whether this halt self-clears. If the owner rules (c) and the leg-2 ruling is pinned, the row closes with the wedge accepted-as-recorded. Zero registry rows, zero DSR debt, no pinned value touched.

Coupling flags (for triage, not edits): PC-1's 08-31 dismissal default rests on pre-halt evidence (expiry watch above). The AVB/BRK-B failed-pair day-3 tripwire is masked, not resolved — with n_submitted 0 the two per-symbol failures cannot occur; it re-arms the day the halt clears.

Triage note — 2026-08-24 (annotation only; the body above is untouched)

Leg 1 is DECIDED and the row narrows to legs 2+3. The owner took option (b) on 2026-08-20 in 955db93: meanrev's safety.max_orders_per_run 150→300 (config + keystone, the deliberate two-touch); momentum and vrp stay at 150. Re-verified from data/state/meanrev/order_log.jsonl: 08-19 n_submitted 0 of 209 targets, 08-20 0 of 161, then 08-21 133 of 149 and 08-24 96 of 73 — the sleeve is submitting again.

The item's own 09-04 falsifier is therefore already answered, and in the direction that CONFIRMS the row, not the one that narrows it. The pinned wording was "if by 2026-09-04 meanrev has resumed submitting with NO config or code change, the wedge-persistence claim is falsified". A config change was required to clear the wedge, so wedge-persistence stands as claimed. Legs 2 and 3 stand independently either way, as the item said.

Leg 2 has since been measured, not just predicted. The daily audit of 2026-08-21 recorded the clearing-day churn against the phantom base — realized cap-accounted churn 67.2% two-sided vs the 0.5/day cap (97.4% gross incl. cap-exempt emergency exits), with last_targets dated 2026-08-20 carrying 161 weights against n_submitted 0. Durable record: research/2026-08-21_meanrev_clearing_day_churn.md (PR #113, merged 9b2e268). Attribution — legal frequency-scaled catch-up vs phantom-base artifact — was deliberately left to this row and is still open.

Leg 3 is temporarily de-armed on meanrev and re-arms on its own. With the cap at 300 a liquidation of today's book passes the count guard; the book is 219 names as of 2026-08-24 and rising (173→185→196→196→196→219 since 08-17), so the guard re-arms against the kill-switch path as the book approaches 300. The structural point the item makes — the count guard exempts nothing, including an all-sell de-risking batch — is unchanged by the recalibration.

Triage note — 2026-09-07 (annotation only; the body above is untouched)

Read this first: PR #154's "leg 3" is IGD-1's leg 3, not this row's. #154 (ee68ebe, 2026-09-06) is titled "IGD-1 leg 3 (owner ruling) + FOS-1" and rules the failed-order escalation shape (exit 4 on a NEW de-risking failure). It does not touch the runaway-order count guard. Recorded because the titles collide and a reader scanning git log would reasonably conclude otherwise.

Leg 2 — STILL LIVE, verbatim. daily.py:1795-1803 persists ledger["last_targets"] guarded only by if not self.pipeline.dry_run: (:1796); execute_orders runs at :1862. No halt guard, no recorded semantics ruling, no pinning test.

Leg 3 — the core is STILL LIVE; only its compounding facet closed. KSP-1 (#151, 47ea024) fixed the side-effects this row named: _liquidate_to_cash now reads the halt state (daily.py:1222-1223) and on a halt advances nothing, the kill-switch active: True publish is deferred through _kill_switch_pending (:1103-1106 → :1227-1230), and the Kelly snapshot is cleared only in the non-halt branch (:1231-1234). The blockage itself is untouched: safety.py:261-267 still counts len(orders) with no exemption, and the only all_de_risking exemption remains scoped to the daily-loss breaker (safety.py:225-232). The code's own comment at daily.py:1213 names "RWG-1 leg 3: the count guard blocks any >150-name book" as a still-live premise — so the fix that landed knows it did not close this.

Arming status re-measured, and it moved the wrong way. The 08-24 note predicted leg 3 would re-arm as the book approached the 300 cap; the 08-31 note recorded the book falling. It then climbed: 203 (08-28) → 233 → 250 (09-01) → 248 → 243 → 239 (09-04). On 2026-09-01 meanrev submitted 241 orders against its 300-order cap — the closest it has come since the 08-19/20 halt that needed an owner config change to clear — and a kill-switch liquidation of that day's 250-name book would have been 250 sells, 50 short of a HALT. Momentum is clear (67 names against 150).

Consequence for sequencing. The row's own text says legs 2 and 3 resolve in one sitting with a ruling; SAC-1's cap note asks to be sequenced first so the ruling is made once. Triage carries both into this week's decide-list as one item on that basis, and makes no ruling itself — every path here is the fail-closed safety layer.