Atlas Ruling — Post-S40 Guard Architecture Audit¶

To: Vesper, Katja, Orion From: Atlas Date: 2026-04-22 Subject: RULING — Post-S40 Guard Architecture Audit (S53 Hold / Structural Corrections Required)

Executive Summary¶

S53 remains on hold until two structural corrections are made:

Drift condition C state semantics are fixed
Idle-sourced episode accounting is separated from active-sourced episode accounting

The containment patch already merged was necessary but not sufficient. S52 proved that.

Core Conclusion¶

The engine is currently overconstrained by emergent guard interactions.

Katja's complaint is valid. This is not just "market hostile." This is not just "one more bug."

The correct move: - Contain the immediate blocker ✅ (done) - Simplify the control architecture deliberately - Not rollback to S40 — truth safeguards, reconciler corrections, and ANCHOR_IDLE are conceptually correct - The issue is the composition, not the existence, of these safeguards

Rulings on Each Issue¶

Issue 1 — Drift C evaluates while ANCHOR_IDLE¶

Ruling: Approved and confirmed as correct containment.

Already fixed. No further debate needed.

Issue 2 — Idle-sourced episodes count against same budget as active-sourced¶

Ruling: Architecturally incorrect. Must be split.

Active-sourced episode = engine was participating and encountered operational/safety risk. Idle-sourced episode = engine was already paused for regime reasons and another guard observed a consequence of that pause.

These are semantically different classes of event and must not consume the same episode budget.

Required change: Split episode accounting into active_episode_budget and idle_escalation_budget (or equivalent structurally distinct accounting). Exact numbers not yet ruled — ruling is that they cannot remain pooled.

Issue 3 — Fill history carries across ANCHOR_IDLE boundary (FLAG-050)¶

Ruling: Must be reset on ANCHOR_IDLE ENTRY (not exit).

Once the engine enters ANCHOR_IDLE, the prior active fill pattern is no longer a valid live control context. Carrying it forward treats the pause as just another active interval — that is the double-penalty the audit describes.

Required change: - Reset _drift_ticks_since_opposing_fill on ANCHOR_IDLE entry - Reset any drift-C-specific rolling state that depends on active quoting continuity - Preserve only metrics that remain meaningful across idle, if any

This ruling is specific to the control history used by drift condition C. Do not reset unrelated system state casually.

Issue 4 — 3-episode limit causes deterministic termination in hostile regimes¶

Ruling: Current limit is too blunt under the present state model. Re-scope required.

The current form is acting as a hidden session-duration override. That is not acceptable.

Required change: - Active-sourced episode limit remains - Idle-sourced episode count must not share that limit - Idle should be allowed to wait

This is exactly why ANCHOR_IDLE exists.

Issue 5 — FLAG-048 warm-up and episode ceiling are incompatible¶

Ruling: Interaction is real and must be resolved.

The current architecture prevents the calibration layer from ever reaching control relevance in the very regimes it was designed to correct. That is not acceptable.

Required implication: Do not evaluate FLAG-048 viability again until drift-C idle carryover is fixed, episode accounting is separated, and the engine can survive long enough to complete warm-up. Until then, any "FLAG-048 failed" conclusion is invalid.

Issue 6 — "Bad regime is not a reason to terminate" violated behaviorally by drift C¶

Ruling: Correct. Must be corrected.

The current implementation undermines the Atlas-locked principle through an indirect path. That path is the drift-C-mediated episode burn during idle.

Additional Ruling — Drift Guard Structure¶

The audit surfaces a deeper question: should condition C still live in the same conceptual bucket as A and B?

Ruling: Not without requalification.

A and B are true active-trading imbalance/risk signals. C is currently functioning more like a participation continuity watchdog or rebalancing opportunity timer. That is a different semantic class.

New instruction: Treat drift condition C as a special-case control, not as an unquestioned peer of A/B. Full structural split not ordered today — placed under formal review.

Immediate Engineering Path (before S53)¶

Required before S53: 1. Containment fix remains in place ✅ 2. Reset drift-C relevant fill history on ANCHOR_IDLE entry 3. Separate idle-sourced and active-sourced episode accounting 4. Confirm engine can survive long enough for FLAG-048 warm-up to actually become active

Only then is S53 meaningful.

What Stays¶

The following remain directionally correct: - Truth reconciliation - Explicit cancellation semantics - ANCHOR_IDLE as regime pause - Cooldown logic as anti-oscillation mechanism - Anchor recalibration path (pending proper warm-up opportunity)

What Changes¶

Drift C cannot treat idle time as active exposure time
Drift C fill history cannot persist through idle entry
Idle escalations cannot burn the same episode budget as active degradation
The system must be allowed to wait out a bad regime without silently terminating through a side path

Instructions to Vesper¶

Refine the audit package into a short execution note covering: - Which state variables reset on idle entry - What counts as idle-sourced vs active-sourced episode - What success looks like for the next validation session

Instructions to Orion¶

Proceed on: 1. Drift-C state reset on ANCHOR_IDLE entry 2. Split or equivalent separation of idle-vs-active episode accounting 3. Test coverage for: - Idle entry resets C counter - Post-idle quoting is possible - Idle does not consume active episode budget - FLAG-048 warm-up can complete in hostile anchor conditions if no other true safety guard fires

Delegation Model (Atlas clarification)¶

Vesper owns: audit prep, change ledger, session timeline, issue classification, flag framing, task packaging for Orion, session analysis, architectural tension spotting, validation planning, VPS migration prep, execution notes.

Orion is reserved for: exact code-path truth, implementation, narrow engineering answers, dangerous or subtle changes (state machine, guard interactions, DB logic, reconciler).

Atlas stays on: architecture rulings, priority/sequence calls, simplification decisions, deciding what stays/changes/gets split.

Rule: If the task is comparative, organizational, framing, or audit-prep → Vesper. If the task is code-exact or implementation-heavy → Orion. If the task is deciding what the system should do → Atlas.

— Atlas 2026-04-22