Skip to content

[C] Atlas Alignment — Pre 7.3 Audit Addendum

To: Orion (he/him) From: Atlas CC: Vesper (she/her), Katja (Captain) Date: 2026-04-18

Orion —

Vesper's audit is correct and must be executed as written.

This addendum expands the scope to ensure we are not only fixing visible issues, but verifying full system integrity before Phase 7.3.

1. CONFIG → RUNTIME → BEHAVIOR TRACEABILITY (CRITICAL)

We are not just verifying config loads. We must verify:

config → parsed object → runtime variable → actual behavior

Add structured startup logging for each critical parameter:

  • raw YAML value
  • parsed config value
  • runtime value used
  • first tick confirmation

Example:

max_xrp_exposure:
  yaml: 150.0
  parsed: 150.0
  runtime: 150.0
  first_tick_check: PASS

Focus parameters: - risk.max_xrp_exposure - risk.max_rlusd_exposure - strategy.bid_offset_bps - strategy.ask_offset_bps - momentum thresholds - duration

2. DUAL SOURCE OF TRUTH AUDIT (HIGH RISK)

We now have multiple state layers:

  • YAML config
  • engine_state (DB)
  • in-memory state
  • XRPL balances

You must confirm:

There is NO parameter divergence across layers.

Specifically: - no risk limits cached in DB - no silent fallback defaults overriding YAML - no stale values between runs

3. INVENTORY CONSISTENCY MODEL (CRITICAL)

Define explicitly:

What is the source of truth for inventory?

Then verify alignment:

  • XRPL wallet = ground truth
  • InventorySnapshot = derived truth
  • DB state = persisted truth

Required invariant:

post_shutdown_inventory == XRPL settled balance (after cancels confirmed)

Add test: - shutdown engine - wait 1 ledger close - fetch XRPL balances - compare vs DB snapshot

4. ORDER RESERVE DISTORTION (VERY IMPORTANT)

XRPL behavior:

  • XRP balance includes reserves in open offers
  • RLUSD balance excludes reserves

This creates asymmetric distortion.

You must confirm what the engine uses:

total balance vs available balance

Required rule:

Trading logic MUST use available (tradable) balance.

If not → inventory skew logic is invalid.

5. SHUTDOWN SEQUENCE INTEGRITY (CRITICAL)

Verify exact shutdown ordering:

  1. stop quoting
  2. cancel orders
  3. wait for confirmation (or timeout)
  4. snapshot inventory
  5. write valuation
  6. close session

Required guarantee:

No step is skipped silently.

Add explicit logging per step.

6. WAL / DB WRITE CONSISTENCY

Beyond checkpointing, verify:

Write durability: - commits are atomic - no partial writes

Write ordering: 

fills → inventory → valuation → session state

Never allow: - valuation before inventory - session close before final writes

7. HALT LOGIC — SINGLE SOURCE OF TRUTH

Guarantee only ONE halt_reason per session.

Priority order: 1. duration elapsed 2. risk halt 3. manual stop

Add explicit halt source enum.

Do not infer from last tick.

8. ASYNC XRPL SAFETY (FLAG-029 EXPANSION)

Unawaited coroutine = real risk.

You must: - ensure all async calls are awaited or explicitly handled - confirm cancel success path - log failures

Otherwise: order cancellations may silently fail.

9. NOT-AT-TOUCH DIAGNOSTIC (NEW)

Add per-tick metrics:

  • distance_to_clob_bid
  • distance_to_clob_ask

Track:

% time within 2 bps of touch

This becomes the primary competitiveness signal.

10. SILENT FAILURE ELIMINATION

Rule:

Any failure affecting: - session lifecycle - inventory - risk

Must log at ERROR level (never debug).

11. FINAL AUDIT GOAL

We are proving:

The engine is internally consistent,
externally correct,
and fully observable.

12. GO / NO-GO BEFORE PHASE 7.3

Phase 7.3 may proceed ONLY if:

  • config mismatch resolved
  • inventory snapshot validated vs XRPL
  • shutdown sequence verified
  • async issues resolved
  • halt classification corrected
  • no silent failures remain

No partial confidence.

We are transitioning from:

working system

to:

reliable trading system

— Atlas