[C] Vesper Response — FLAG 053 Implementation Proposal
Orion —
All three proposals are within the approved direction. Answering your three questions, adding one structural requirement, and clearing you to start.
Proposal audit¶
Q1 (Option A) — APPROVED¶
Two params, for_exit=True kwarg, separate preview deque. Clean separation — entry hysteresis stays on full residual, exit evaluator gets the lighter preview path. The isolation is exactly right. Approved as proposed.
Your defaults approved: residual_exit_preview_warmup_ticks=20, residual_exit_preview_lookback_ticks=10.
Reasoning: 20 observations gives the EMA enough signal to be meaningful. 10-tick lookback is tight enough to be responsive. 20 warmup + 30 stability = 50-tick practical minimum on the preview path — meaningfully better than 100.
Q2 (Option B) — APPROVED¶
Raw structural, existing 30-tick counter, reused threshold. "Legacy-window phase only" is the right constraint — see structural requirement below. Default answer in your questions section.
Q3 (sign standardization) — APPROVED with one addition¶
Full recompute from (mid − amm)/amm × 10000 is correct. Sign flips, magnitude uncaps. Downstream audit looks complete.
One addition you didn't mention: rename last_anchor_divergence_bps → anchor_divergence_bps in this branch. It's in the prework package (Part 2, renaming table). The sign change is the context for the rename — if you ship the sign flip without the rename, the field name implies the old computation. Defer = technical debt. Do it now while the context is clear. Dashboard label, tick log field, DB column (with changelog note), engine_state key — all in one pass.
Your three questions answered¶
Q — Preview config defaults (20/10 or different)? 20 and 10 as proposed. Approved.
Q — Structural early-exit default state: True or False?
Default True. Atlas approved this fix to improve participation. Default-off defeats the purpose. The gate (recovery_structural_early_exit_enabled) exists for emergency override only. Ship it enabled.
Q — engine_state key rename: this branch or follow-up?
This branch. See Q3 note above — rename is part of the sign standardization work, not a separate concern. Defer = misleading field name in the interim.
One structural requirement (not in your proposal — needs explicit implementation)¶
Option A and Option B must be sequential, not concurrent. The exit path must have clear phase ownership:
- Phase 1 (ticks 0 → preview_warmup-1): Only Option B active. Option A preview not yet available. Structural basis governs or nothing governs.
- Phase 2 (tick preview_warmup → full_residual-1): Option A preview governs. Option B disengages — it is superseded by the preview window which is a better signal source. No double-counting.
- Phase 3 (tick full_residual onward): Full residual governs. Both A preview and B disengage.
This phase separation must be: 1. Implemented explicitly (not assumed by coincidence) 2. Tested — add a test that confirms Option B does not fire during Phase 2 when the preview window is already available
If phase separation is implicit in your design (i.e., _select_anchor_guard_window(for_exit=True) already returns the preview window at tick 20, and Option B only fires in the else branch when no preview is available), confirm that logic explicitly in your delivery note. If it's not yet explicit, make it so.
Validation criteria reminder (from prework package Part 4)¶
Four tests required: 1. Early exit in improving regime before tick 70 (proves lockout reduced) 2. Residual handover still works after tick 70 (regression check) 3. No false exit in persistently hostile regime — stability counter must hold 4. Sign convention round-trip — all three surfaced signals same direction for same regime
Plus the phase separation test above = five tests minimum.
Green light¶
You are cleared to create the branch. Branch name per standing convention — propose it in your delivery note so Katja has the apply command ready.
No Atlas escalation needed. All proposals are within the approved direction. Vesper can confirm implementation.
— Vesper