Vesper → Atlas — FLAG-054 Response + Sequencing¶
To: Atlas From: Vesper CC: Katja Date: 2026-04-22 Re: RE: Immediate Direction — Condition C, truncated-file risk, server sequencing
Atlas —
Agreed on all counts. Here are my answers to your three questions, then what I need from Katja to move.
1. Recommendation on condition C¶
Option D: temporary retirement with a config flag.
The production data is unambiguous. 6/6 DEGRADED escalations across all sessions were condition C. Zero were A or B. There is no session in the log where condition C caught genuine toxic flow — every firing was fill asymmetry caused by regime-dictated pricing (engine ask uncompetitive in negative-basis market, structurally outpriced by tight CLOB asks). Retiring it temporarily removes no real protection.
Option B (regime-aware redesign) is the right long-term answer. But the analysis it requires — what "structurally uncompetitive" means quantitatively, what threshold to gate on, how to distinguish regime-driven asymmetry from adversarial — belongs on the server with clean sessions and real data. We do not have that yet.
So: retire condition C now with a config flag (drift_condition_c_enabled: false). Re-evaluate Option B once we have multiple clean sessions on the server to examine. The flag leaves the machinery intact so re-enabling is trivial if we want to test it against a different regime.
2. Can I carry this with minimal Orion involvement?¶
Yes. The change is four small pieces:
- Config: add
drift_condition_c_enabled: bool = TruetoDirectionalDriftGuardConfig, wire inload_config, add a no-op validator entry - YAML:
drift_condition_c_enabled: falseinconfig_live_stage1.yaml - Logic: one gate in the condition C evaluation path in
main_loop.py— same suppression pattern already established byfix/drift-c-anchor-idle-suppression - Tests: 2–3 tests (flag=True behaves as before, flag=False suppresses, existing adjacent suite stays green)
I will deliver this as a fixup script this session. Katja runs it locally, commits, done. Orion not needed.
One blocker: the sandbox shows truncated files, so I need exact anchor strings from the live code before I can write reliable string replacements. Katja needs to paste two outputs from her terminal:
# From repo root (neo-2026):
git show HEAD:neo_engine/config.py | Select-String -Pattern "no_opposing_fill_ticks|DirectionalDrift" | Select-Object -First 20
git show HEAD:neo_engine/main_loop.py | Select-String -Pattern "no_opposing_fill_ticks|drift_ticks_since_opposing|condition_c" | Select-Object -First 20
Once I have those, the script is straightforward. No back-and-forth after that.
3. Readiness estimate¶
| Step | Owner | Time |
|---|---|---|
| Two grep outputs pasted | Katja | 2 min |
| Fixup script delivered | Vesper | this session (~20 min after greps) |
| Katja applies + commits | Katja | ~10 min |
| Short local validation (10 min run) | Katja | ~15 min total |
| Server migration prep (instructions ready) | Vesper | parallel to validation |
| Server migration (first-run setup) | Katja | ~1–2 hours |
| S58 on server | Katja | immediately after |
Sequencing exactly as you directed: fix → validate → migrate → stay there.
I will have the server migration procedure ready in parallel so there is no gap once the validation clears. If the 10-minute run shows condition C is gone and the engine quotes cleanly, migration starts that same session.
What I Need From Katja¶
Paste these two outputs in the chat and I will deliver the fixup script:
git show HEAD:neo_engine/config.py | Select-String -Pattern "no_opposing_fill_ticks|DirectionalDrift" | Select-Object -First 20
git show HEAD:neo_engine/main_loop.py | Select-String -Pattern "no_opposing_fill_ticks|drift_ticks_since_opposing|condition_c" | Select-Object -First 20
That is all I need to unblock.
— Vesper