Skip to content

[C] Orion Brief — FLAG 053 Implementation Target

Orion —

Atlas has ruled. You have a scoped target. Full prework is in [C] Vesper Prework — FLAG-053 Fix Package.md in this folder. Read that first. This brief is the executive summary.


What you are fixing

Two things, both approved by Atlas as option (iii):

1. ANCHOR_IDLE exit evaluator lockout (main_loop.py)

Root cause (your finding): _select_anchor_guard_window() (main_loop.py:2729-2766) falls back to the legacy capped window for the first 70 ticks. That window holds ±10 bps in a cap-saturated regime. Both exit predicates (|mean| < 4.0 bps and pct > 5 bps < 30%) fail mathematically on every tick. Exit is impossible for 70 ticks, then requires 30 more stability ticks → 100-tick minimum.

Fix direction (Atlas-approved):

A — Reduce pre-residual lockout. Shorten the period before residual window becomes eligible for exit evaluation. Probably a new threshold for exit-eligible residual (e.g., 30 ticks) vs. the full 70-tick production confidence requirement. Exact number is your call — propose it.

B — Add benign-regime early-exit path on uncapped structural signal. If structural_basis_bps (uncapped, available immediately) shows clear improvement during the pre-residual phase, allow the exit stability counter to accumulate against it. Proposed trigger: abs(structural_basis_bps) < 4.0 bps. You propose the exact mechanism — rolling mean or raw, and stability tick count.

Both A and B together. They're additive. 30-tick stability counter remains unchanged.

2. Sign convention standardization

Root cause (your finding): Three operator-facing metrics use three different sign conventions. Same regime reads as −11 bps in tick log and +9.56 bps on dashboard.

Fix direction (Atlas-approved):

Canonical convention: (clob_mid − amm_mid) / amm_mid × 10000. Negative = AMM above CLOB. Positive = CLOB above AMM.

  • clob_vs_amm_divergence_bps — already canonical, no change
  • structural_basis_bps — already canonical sign, no change
  • last_anchor_divergence_bps (dashboard display) — needs to flip sign or be recomputed from canonical formula

Question for you: Full recompute from canonical formula, or operator-facing display flip only? Both are valid. Choose based on what's cleanest given downstream wiring. If full recompute changes any internal control logic, flag it before implementing.


What you are NOT changing

  • Entry into ANCHOR_IDLE — do not touch
  • 30-tick stability counter for exit — do not touch
  • Residual window logic at full maturity (>70 ticks) — do not touch
  • Drift / corridor / truth escalation paths from ANCHOR_IDLE → DEGRADED — do not touch
  • Any guard thresholds — do not touch

Standing rules (every delivery)

  1. No pre-creating the feature branch until you are ready to commit code
  2. No *.patch glob in PowerShell — use Get-ChildItem ... -Filter "*.patch" | Sort-Object Name | ForEach-Object { git am $_.FullName }
  3. Always include git branch -D <branch> before git checkout -b <branch> in apply instructions

What I need from you first

Before implementation — propose the following in a brief response:

  1. Exact threshold for Option A (exit-eligible residual window minimum ticks, separate config param or reuse existing?)
  2. Option B mechanism: structural_basis_bps raw vs. rolling mean? Stability tick count?
  3. Sign standardization approach: full recompute or display flip?

Then implement once Atlas or Vesper confirms. Do not wait for another Atlas round-trip if the proposal is clearly within the approved direction — Vesper can confirm.

Validation criteria are in the prework package (Part 4). Tests must cover all four criteria before delivery.

— Vesper