Atlas Ruling — FLAG-042 Approved + Recovery Design Spec¶

To: Vesper (she/her), Orion (he/him) From: Atlas (he/him) CC: Katja (Captain) Date: 2026-04-21 Re: S43/S44 evidence, FLAG-042 advancement, session strategy

1. Prior Ruling Reassessment¶

FLAG-042 deferral was conditional on insufficient regime variation data. S44 invalidates that condition. Evidence in hand: - S43 → fully hostile regime (no recovery opportunity) - S44 → cycling regime with threshold re-entry

The missing piece is now present.

2. Updated Ruling — FLAG-042¶

APPROVED: FLAG-042 moves into current phase (no longer deferred to Phase 7.4).

Reason: S44 shows empirical intra-session regime normalization — anchor error crossing threshold mid-session, guard remaining latched, system failing to re-engage despite valid opportunity. This is no longer theoretical.

3. Clarification — Not a Strategy Change¶

FLAG-042 is NOT about making the system more aggressive. It is about allowing the system to re-enter once safety conditions are restored. Guards are not weakened — controlled re-arm logic is added.

4. Recovery Design Constraints (Non-Negotiable)¶

4.1 Hysteresis Required¶

Entry threshold ≠ exit threshold. Example: - Enter DEGRADED: mean error > 6 bps AND prevalence > 40% - Exit DEGRADED: mean error < 4 bps for sustained period

Prevents oscillation.

4.2 Time Stability Requirement¶

Exit must require persistence: N consecutive ticks OR time window (60–120s stable). Not single-tick recovery.

4.3 State Reset on Exit¶

On exiting DEGRADED: reset rolling windows, reset guard counters, treat as fresh regime.

4.4 One Recovery Attempt per Episode¶

If system exits DEGRADED and re-enters quickly: do NOT loop indefinitely. Second failure within same episode escalates to HALT.

5. Guard-Specific Recovery Rules¶

Anchor Saturation (Primary — required for S45)¶

Exit condition: - mean anchor_error_bps < 4 bps - sustained for N ticks (recommend 20–40 ticks) - AND prevalence < 30%

Directional Drift (Secondary)¶

Exit condition: - no same-side fills for N ticks - OR opposing fill observed

Keep minimal for now.

Inventory Corridor¶

Exit condition: - inventory % inside corridor - sustained for corridor_lookback_ticks

6. Q1 — FLAG-042 Acceleration¶

YES. FLAG-042 is now part of current work.

7. Q2 — Clean Session Strategy¶

Option B (relax guards temporarily) — REJECTED. Do not compromise guard integrity for convenience. Option C (add recovery) — SELECTED. This is the correct path.

8. Q3 — Phantom Fill Loop (FLAG-037)¶

Do NOT expand FLAG-037 yet. Current <300s logic still needed for fill correctness. Removing phantom fills prematurely risks breaking reconciliation.

Updated priority: (1) FLAG-042 recovery → (2) additional session data → (3) refine FLAG-037.

9. Next Steps (Locked)¶

Orion implements FLAG-042 — anchor recovery first, minimal viable logic, no overengineering
Run S45 — validate recovery behavior, confirm no oscillation, confirm proper re-entry
Observe — time in DEGRADED, number of recoveries, fill quality post-recovery
Do NOT — touch offsets, relax thresholds, expand FLAG-037

10. Final Note¶

S42 proved: we can survive bad markets. S44 revealed: we currently cannot re-enter good ones fast enough. FLAG-042 is the bridge between those two states.

Proceed with implementation.

— Atlas