[C] Atlas Alignment — Post Injection Regression Rulings

To: Vesper CC: Katja (Captain) From: Atlas Date: 2026-04-17

Executive Read¶

You now have: - ✅ State integrity confirmed (no fills vs total bug in guards) - ✅ Capital system correct - ❌ Zero fills = market interaction problem, not state bug

Root cause is now very likely:

Anchor cap + increased size → quotes no longer competitive vs CLOB

Everything else (guards, configs) was either noise or misleading instrumentation.

RULINGS¶

✅ RULING 1 — FLAG-034 (Session Summary Fix): APPROVED — IMPLEMENT¶

Right now:

Session summary shows FILLS-ONLY inventory
Engine operates on TOTAL inventory

That is dangerous because debugging decisions ≠ actual system state.

The proposed fix mirrors InventoryManager.rebuild(), uses capital_events overlay, is read-only, no schema change. Correct.

One requirement: Add a comment:

# NOTE: Display uses TOTAL inventory (fills + capital overlay),
# matching live engine state, not ledger-only state

This prevents future confusion.

Conclusion: Ship FLAG-034.

⚖️ RULING 2 — `max_inventory_usd`: RETIRE IT (Option A)¶

Right now max_inventory_usd = misleading diagnostic only.

Wiring it in would: - Introduce a new guard dimension - Create interaction risk with existing drift/skew logic - Blur attribution

Already have drift-based skew + exposure caps. A third constraint is unnecessary.

Important principle:

Do not introduce new control surfaces while diagnosing execution issues

Action: - Remove from logs - Remove from config - Remove from mental model

Conclusion: Kill it cleanly.

⚖️ RULING 3 — `anchor_max_divergence_bps`: DO NOT CHANGE YET¶

Diagnosis is correct:

Anchor cap is causing quote displacement vs real market

BUT: only ONE post-injection session (S35) showing zero fills. Not enough data to retune anchor behavior.

Just changed: capital, size (10→15), inventory composition, risk limits. Changing anchor now loses causal clarity completely.

What I want instead: Run one clean diagnostic session at current settings and confirm:

Is zero-fill behavior persistent?

Interpretation of current data:

CLOB-AMM divergence ~20–23 bps
cap = 10 bps
→ anchor lags ~10–13 bps
→ quotes displaced ~10 bps

At size=15, that displacement becomes non-trivial. But need confirmation: is this a one-session artifact or a stable regime condition?

Conclusion: Hold anchor at 10 for ONE controlled run. Then decide.

Additional Finding (not asked — critical)¶

RLUSD headroom ≈ 22 RLUSD with base_size = 15 → ~30 RLUSD for 2 sides. System is near RLUSD constraint boundary.

Even if not currently blocking, it can: - Distort quoting - Limit rebalancing behavior - Bias one side

I want Orion to check:

Is RLUSD exposure limit affecting quote eligibility or sizing?

This could be a secondary constraint interacting with anchor.

Next Step Plan¶

Step 1 — Apply fixes - ✅ FLAG-034 → merge - ❌ Remove max_inventory_usd completely

Step 2 — DO NOT CHANGE STRATEGY YET Keep:

anchor_max_divergence_bps: 10.0
base_size_rlusd: 15.0

Step 3 — Run ONE diagnostic session Goal: confirm whether zero-fill condition persists.

Step 4 — Capture during that session: - Effective quote distance vs CLOB - Anchor vs CLOB gap - Number of near-touch events - Fill conversion rate - RLUSD constraint interaction

Step 5 — Decision tree after that run:

Case	Observation	Action
A	Still zero / near-zero fills	Widen anchor cap 10 → 15
B	Fills return but weak	Partial widening 10 → 12–13
C	Fills normal	S35 was regime anomaly — keep cap at 10

Final Take¶

You don't have a broken system. You have:

a system that is now large enough for anchor constraints to matter

That's a good problem — it means you're in the scaling phase.

Final Answers (clean)¶

FLAG-034 → APPROVED
max_inventory_usd → REMOVE
anchor_max_divergence_bps → HOLD (no change yet)

— Atlas