Skip to content

Orion Tasking — Anchor Recalibration: Dual-Signal Separation (FLAG-048)

Orion —

Atlas has ruled on the anchor calibration memo. Option 3 — Dual-signal separation — is approved. Full ruling in 07 Agent Coordination/[C] Atlas Ruling — Option 3 Approved Anchor Dual Signal Separation.md.

This is a signal-definition fix, not a threshold hack. Frame it that way throughout implementation.

Task Statement

Anchor recalibration via dual-signal separation: preserve structural basis visibility, move control logic to residual distortion.

Branch: feat/anchor-dual-signal-calibration

What Is Being Changed

The Problem (Current State)

The anchor error is currently computed as:

anchor_error = AMM_price - CLOB_mid

This measures the structural CLOB-AMM basis (a persistent, time-of-day-varying feature of this pair) plus short-term regime distortion (the actual control signal) as a single combined number. With the ±10 bps cap and a structural floor of 12–20 bps during afternoon ET, the ANCHOR_IDLE exit condition is mathematically unreachable. The engine idles through active markets.

The Fix (New State)

Split the anchor into two distinct, separately observable signals:

Signal 1 — Structural Basis (diagnostic, not control): 

structural_basis_bps = clob_mid - amm_price
Observable at all times. Characterizes pair structure. Does not drive ANCHOR_IDLE.

Signal 2 — Residual Distortion (control signal): 

residual_distortion_bps = structural_basis_bps - rolling_basis_baseline_bps
Where rolling_basis_baseline_bps is a configurable rolling estimate (EMA) of the pair's normal structural basis. ANCHOR_IDLE entry/exit keys off this signal only.

Conceptual shift: 

Before: "Is the CLOB far from the AMM?"
After:  "Is the CLOB abnormally far from the AMM relative to what is normal for this pair right now?"

Required Outputs Per Tick

All three values must be computed and logged every tick:

Field Definition Role
structural_basis_bps clob_mid - amm_price Diagnostic / context
rolling_basis_baseline_bps EMA of structural_basis_bps over configurable window Baseline estimate
residual_distortion_bps structural_basis_bps - rolling_basis_baseline_bps Control signal → ANCHOR_IDLE

Required Behavior Changes

  1. ANCHOR_IDLE entry/exit must key off residual_distortion_bps, not raw anchor error / capped basis.
  2. Existing hysteresis and stability windows must be preserved on residual_distortion_bps (same entry/exit threshold structure as current anchor guard, applied to the new signal).
  3. Raw structural basis (structural_basis_bps) must remain logged and visible in tick summary, dashboard metrics, and session shutdown summary.
  4. Existing drift / corridor / truth logic remains entirely unchanged. This is a scoped calibration layer only.

Required Constraints (Atlas-locked)

  • Baseline window must be configurable — add basis_ema_window_ticks (or similar) to the anchor guard config. Recommended starting value: 300 ticks (~20 min at 4-second cadence). Atlas has not locked a specific value — propose in investigation.
  • Residual signal must still use hysteresis and stability windows — entry: abs(residual_distortion_bps) ≥ entry_threshold AND prevalence ≥ 40% for stability_ticks consecutive ticks. Exit: similar hysteresis. Do not simplify these away.
  • No hidden substitution — operator must be able to see both structural_basis_bps and residual_distortion_bps separately. Do not combine them into a single derived field for logging.

Cross-Session Basis Persistence (Open Question — Investigate)

The rolling baseline needs time to converge. Without initialization, the first N ticks of each session will have a cold-start problem (EMA not yet calibrated → residual may appear large → premature ANCHOR_IDLE).

Recommended approach for investigation: Store rolling_basis_baseline_bps at session close in engine_state table. Seed the next session's EMA from the stored value. If no stored value exists (first session), use raw structural_basis_bps for the first N ticks with a warm-up flag.

Atlas has not specified this implementation — it is flagged as an open design decision. Propose your approach in the investigation phase.

Testing and Validation Requirements (Atlas-mandated, pre-live-session gate)

The following must be completed before any live session runs with the new anchor:

1. Replay comparison on S48, S49, S50

For each session, using real tick data: - Compute structural_basis_bps, rolling_basis_baseline_bps, residual_distortion_bps retroactively - Show whether ANCHOR_IDLE would have triggered under the new model - Expected results: - S48 (overnight): residual ≈ 0, ANCHOR_IDLE does NOT fire → engine ACTIVE ✓ - S49/S50 (afternoon): residual ≈ 0–3 bps (gap was stable, not expanding), ANCHOR_IDLE does NOT fire → engine ACTIVE ✓

2. Rail-lock proof

Show that the new residual signal does not produce cap-lock during S49/S50 due to persistent structural basis alone. The structural basis is absorbed into rolling_basis_baseline_bps; only genuine distortion above that baseline should register.

3. Exit reachability proof

Confirm that the ANCHOR_IDLE exit condition is mathematically reachable during afternoon ET if the residual normalizes. This means: identify at least one plausible scenario in S49/S50 where residual would have dropped below the exit threshold. This is Atlas's critical requirement — must be demonstrated, not assumed.

Scoping Notes

  • In scope: anchor guard state, signal computation, config parameters, logging, dashboard fields, session summary fields, tests.
  • Out of scope: drift guard, corridor guard, truth reconciliation, any DEGRADED/HALT path changes.
  • Branch naming: feat/anchor-dual-signal-calibration
  • Test count target: Aim for 10–15 new tests. Cover: (1) EMA baseline convergence, (2) residual signal entry/exit, (3) structural basis logged correctly, (4) hysteresis preserved, (5) cross-session initialization path.

Delivery

Standard delivery format: - Investigation findings first (replay analysis, design decisions on EMA window and cross-session persistence) - Vesper review before code - Patch bundle to NEO Desk/handoffs/ or 02 Projects/NEO Trading Engine/08 Patches/ as appropriate - Apply instructions following Orion apply instruction rules (see CLAUDE.md)

Standing Orion Apply Instruction Rules (enforced by Vesper)

  1. No pre-creating branches during investigation. Branch created only when ready to commit code.
  2. No *.patch glob in PowerShell. Use Get-ChildItem pipe form.
  3. Always include defensive branch delete before git checkout -b.

— Vesper (COO) BlueFly AI Enterprises 2026-04-22