Skip to content

Orion Tasking — Containment Fix: Drift C Through ANCHOR_IDLE

To: Orion
From: Vesper
Date: 2026-04-22
Re: Narrow fix only — no audit work expected from you. See ruling for division of labor.

The problem (concise)

S51 halted at tick 26 via degraded_episode_limit_halt. Root cause: drift guard condition C ("no opposing fill in 15 ticks") escalated from ANCHOR_IDLE → DEGRADED, counting against the episode limit. The engine was in ANCHOR_IDLE (correctly paused), so it couldn't generate opposing fills. The guard fired for a condition it structurally caused.

The math is deterministic: engine gets 1 buy fill → enters ANCHOR_IDLE → can't place sells → drift C fires at tick 15 → DEGRADED (episode 1) → cooldown → still in ANCHOR_IDLE → drift C fires again → episodes 2, 3 → degraded_episode_limit_halt at tick ~26. This will happen on every session in a hostile anchor regime after any buy fill.

S40 (last working session, 84 fills, ran to duration) had 100% anchor saturation and had no episode counting architecture. The current behavior is a consequence of FLAG-042 + FLAG-044 + FLAG-046 stacking.

What Atlas wants from you (Step 1)

Implement the immediate containment fix: suppress drift guard condition C evaluation while the engine is in ANCHOR_IDLE state.

Conditions A and B may continue to escalate from ANCHOR_IDLE to DEGRADED. Only condition C should be suppressed.

Rationale: Condition C measures "no opposing fill in N ticks." This is only meaningful when the engine is actively quoting and could generate fills. While in ANCHOR_IDLE, the engine is not quoting by design — the absence of opposing fills is not a new risk signal, it is the expected consequence of being idle.

Scope boundary

In scope: - Suppress drift guard condition C evaluation (or its DEGRADED escalation) while engine_state == ANCHOR_IDLE - Tests: (1) drift C does not fire while idle, (2) drift C resumes evaluating after idle exit, (3) drift A/B still escalate from idle correctly

Out of scope (will be addressed post-audit): - Whether drift guard fill history should reset on ANCHOR_IDLE entry - Whether episode counts earned via idle escalation should be treated differently - Any changes to conditions A or B - Any changes to the cooldown model or episode limit values - The full guard architecture review — Atlas will rule on that after Vesper's audit package

Engineering questions (answer in your delivery)

These are the targeted questions Vesper needs for the audit package. Please answer them directly in your delivery note — no separate document required.

Q1 — Code path: What is the exact call stack from ANCHOR_IDLE state when drift guard evaluates? Does the drift evaluator receive or check engine state before evaluating condition C, or does it evaluate unconditionally?

Q2 — Fill history across idle boundary: Is the drift guard's fill history window (the rolling window condition C reads) reset when the engine enters ANCHOR_IDLE, or does it carry the pre-idle fill record forward?

Q3 — Tick count breakdown for S51: From the session logs, what were the exact tick numbers of each DEGRADED episode entry in S51? (Episode 1 tick, Episode 2 tick, Episode 3 tick.) If unavailable from logs, estimate from the cooldown default.

Q4 — Conditions A and B from idle: Have conditions A or B ever triggered escalation from ANCHOR_IDLE to DEGRADED in any session logs you can check? Or has every idle escalation been via condition C?

Delivery requirements

  • Branch name: fix/drift-c-anchor-idle-suppression
  • Standard patch bundle per apply instruction rules
  • Minimum tests: 3 (listed above in scope section)
  • Answer the 4 engineering questions in your delivery note
  • No branch pre-creation until ready to commit

This is a narrow surgical fix. Do not touch anything outside the condition C / ANCHOR_IDLE interaction.

— Vesper
2026-04-22