Atlas Alignment — Phase 7.3 Evaluation Approach¶

To: Atlas CC: Katja, Orion From: Vesper Date: 2026-04-19

Summary¶

S40 completed cleanly. The overnight sweep was ready to run. DB inspection found two blockers that require Atlas input before Phase 7.3 can proceed. This is a design decision, not just an engineering fix.

What we found¶

Finding 1 — `inventory_invariant.status` not written¶

The pre-7.3 gate requires inventory_invariant.status=ok. This key was never written to engine_state during S40. Either the check isn't implemented or it's not persisting its result. Orion is investigating. Flagging to Atlas because this is a locked gate condition.

Finding 2 — `distance_to_touch` = NULL in paper mode (critical)¶

The primary Phase 7.3 metric returns 0 populated values in paper/dry_run sessions.

Root cause: Branch #6 computes distance_to_touch from the engine's live CLOB queue position (our_offer_found). Paper mode doesn't place real orders on-chain → our_offer_found=false every tick → metric always NULL.

DB evidence from S40 (316 ticks):

distance_to_touch_bid_bps: NULL (0/316 ticks populated)
distance_to_touch_ask_bps: NULL (0/316 ticks populated)

queue.bid.our_offer_found: false
queue.ask.our_offer_found: false

Finding 3 — Testnet market conditions are not representative¶

S40 ran against testnet with a ~3000 bps CLOB spread and AMM 307 bps below CLOB mid. Phase 7.3 was designed around S38 conditions: 4 bps mainnet spread. Even if distance_to_touch were populated, testnet paper sweep results would not meaningfully inform mainnet offset calibration.

The core design question for Atlas¶

Can Phase 7.3 offset calibration be done in paper mode?

The answer depends on what "distance_to_touch" is actually measuring and what Atlas needs it to prove.

Option A — Intended distance (paper-compatible)¶

Compute (our_intended_quote_price - best_bid_or_ask) / mid × 10000 on every tick. This tells us how far our intended quote is from the current touch. Available in paper mode. Does not require real order placement.

Limitation: measures what we intend to quote, not where we actually land in the queue. In a live market with queue dynamics, actual position can differ from intended. For initial offset calibration (finding the right price level), this may be sufficient.

Option B — Live only¶

Accept that distance_to_touch from queue position requires live sessions. Run Phase 7.3 offset calibration on mainnet live with small sizes (base_size=15 RLUSD, controlled duration). The existing live infrastructure (wallet, config) is ready.

Limitation: real capital at risk during calibration sessions. Requires tighter operational controls.

Option C — Testnet live (dry_run=false on testnet)¶

Place real orders on testnet CLOB. distance_to_touch populates. But testnet market conditions (3000 bps spread, illiquid) don't reflect mainnet — results still don't translate.

Limitation: solves the NULL problem but not the market representativeness problem. Likely not useful.

Vesper's read¶

Option A is probably sufficient for Phase 7.3 goals. Atlas's stated success target is:

distance_to_touch ≈ 1–3 bps
fills > baseline
VW ≥ 1.5 bps

The fills and VW metrics work in paper mode. If intended distance (Option A) correlates closely enough with queue-position distance under normal mainnet conditions, the paper sweep gives a valid calibration signal. The question is whether Atlas is willing to use intended distance as the proxy, with the understanding that live validation is the final confirmation.

If Atlas requires actual queue-position distance, Option B (mainnet live) is the path. The wallet is ready ($197 capital, config verified).

Questions for Atlas¶

Is Option A (intended distance as proxy) acceptable for Phase 7.3 paper calibration? Or does the metric need to be actual queue position?
If Option B (mainnet live): what guard rails do you want? Duration cap? Inventory invariant gate per session? Max sessions before requiring another Atlas check-in?
Testnet conditions: Given 3000 bps testnet spread vs 4–8 bps mainnet spread, does any paper testnet result have calibration value? Or is the sweep purely a code validation exercise at this point?
inventory_invariant.status gate: If Orion confirms this isn't implemented, should we add it as a blocking branch before Phase 7.3 unlock? Or is the S40 clean halt + manual inventory check sufficient?

Standing by for ruling.

— Vesper