Skip to content

Orion Tasking — Guard Architecture Fixes (Post-Atlas Ruling)

To: Orion From: Vesper Date: 2026-04-22

Atlas ruling received. Two structural changes required before S53. Full ruling at 07 Agent Coordination/[C] Atlas Ruling — Post-S40 Guard Architecture Audit.md. Execution note at 07 Agent Coordination/[C] Vesper Execution Note — Guard Architecture Fixes Pre-S53.md. Architecture matrix (S40 → current → target) at 07 Agent Coordination/[C] Vesper — S40 vs Current vs Target Guard Architecture Matrix.md.

Context

S52 confirmed that the containment fix alone is insufficient. The engine got a sell fill, CLOB-AMM divergence jumped to +17 bps, and the engine could not recover — drift C counter was still elevated across the ANCHOR_IDLE boundary and blocked quoting for the rest of the session.

Atlas has ruled on two root changes required.

Change 1 — FLAG-050: Reset drift-C fill history on ANCHOR_IDLE entry

Atlas 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."

What to do: - Reset _drift_ticks_since_opposing_fill to 0 when the engine enters ANCHOR_IDLE - Reset any other rolling state that condition C specifically depends on for quoting continuity - Do not reset state used by conditions A or B unless it is shared with C and you confirm it should reset - Do not reset _drift_fills_seen_this_session (cumulative session metric, not continuity-dependent)

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

Before implementing: confirm in your delivery which variables you reset and which you preserve, and why.

Tests required: - Idle entry resets _drift_ticks_since_opposing_fill to 0 - Post-idle engine can quote without immediate drift C re-fire even if pre-idle counter was elevated - A/B state is not disturbed by the reset

Change 2 — Idle-sourced vs active-sourced episode accounting split

Atlas ruling: "Idle-sourced escalations and active-quoting degradations are not the same class of event and must not consume the same episode budget."

What to do:

At DEGRADED entry, check current mode and route the episode increment:

  • If _current_truth_mode() == MODE_ANCHOR_IDLE at the moment of DEGRADED entry → increment idle_episode_count[source]
  • Otherwise → increment active_episode_count[source]

degraded_episode_limit_halt must only fire when active_episode_count[source] reaches the limit. Idle episode count is tracked separately.

Atlas has not yet set the idle episode limit — for now, idle episodes do not trigger halt. Track the count but do not halt on it.

Tests required: - Idle-sourced DEGRADED entry increments idle_episode_count, not active_episode_count - Active-sourced DEGRADED entry increments active_episode_count - degraded_episode_limit_halt fires correctly when active_episode_count reaches limit - Engine can cycle through multiple idle-sourced DEGRADED entries without session termination - Engine can complete FLAG-048 warm-up (50 ticks) in hostile anchor conditions if no active-sourced safety events fire

Branch Structure

Your call: one branch or two. Vesper recommends one branch (fix/anchor-idle-guard-semantics or similar) since both changes are about ANCHOR_IDLE boundary semantics, but do what makes the tests cleaner.

Standing Rules (as always)

  1. No pre-creating branches during investigation. Branch at commit time only.
  2. No *.patch glob in PowerShell — use Get-ChildItem ... ForEach-Object form.
  3. Always include defensive git branch -D <branch> before git checkout -b.

Delivery

  • Delivery memo in 03 Branches/<branch-name>/
  • Confirm which variables you reset and which you preserve for Change 1
  • Vesper will review before Katja applies

— Vesper 2026-04-22