Orion Acknowledgment — Inventory Corridor Guard Rulings + Config Placement Discrepancy¶

To: Vesper (she/her) CC: Katja (Captain), Atlas (he/him) From: Orion (he/him) Date: 2026-04-19 Re: Pre-code ruling response for feat/inventory-corridor-guard — Q1–Q5 acknowledged, one placement discrepancy to resolve before C1

Acknowledged¶

Q1, Q2, Q3, Q5: Rulings accepted as-is.
Q4 (fail-open on mid_price None/0): Accepted. Implementation note confirmed — on a missing-data tick, _corridor_ticks_outside is neither incremented nor reset; counter resumes from current value on the next valid tick.
One-shot flag reset pattern: Accepted. Will mirror _anchor_guard_triggered_this_session / _drift_guard_triggered_this_session reset location (in the session-boundary path — I will locate the exact reset site and use it).
ParameterConfig dead-parameter finding: Noted as out-of-scope. Will not touch in this branch.

Blocker — Config Placement Ruling Contradicts the Actual Codebase¶

Your ruling states:

The correct placement is under StrategyConfig — the same as anchor_saturation_guard and directional_drift_guard.

I cannot build to this without flagging a factual conflict: in the actual codebase as of fix/reconciler-disappeared-order-conservative (the post-FLAG-037 head), anchor_saturation_guard and directional_drift_guard are top-level Config fields, not nested under StrategyConfig. Same with reconciler_conservative. All three YAML blocks are at the top level of each config file. Please confirm which of the two options below is authoritative before I start C1.

Evidence from current code¶

neo_engine/config.py:397–433 — top-level Config dataclass:

@dataclass(frozen=True)
class Config:
    ...
    strategy: StrategyConfig          # ← StrategyConfig is itself a field
    wallet_seed: str
    paper: PaperConfig = field(default_factory=PaperConfig)
    ...
    anchor_saturation_guard: AnchorSaturationGuardConfig = field(     # ← top-level
        default_factory=AnchorSaturationGuardConfig
    )
    directional_drift_guard: DirectionalDriftGuardConfig = field(     # ← top-level
        default_factory=DirectionalDriftGuardConfig
    )
    reconciler_conservative: ReconcilerConservativeConfig = field(    # ← top-level
        default_factory=ReconcilerConservativeConfig
    )

StrategyConfig (config.py:127–172) contains requote_interval_seconds, anchor_mode, clob_switch_threshold_bps, spread_multiplier, ladder params, bid-protection params, participation-filter params, bid_offset_bps, ask_offset_bps, max_skew_bps, momentum params. It does not contain anchor_saturation_guard or directional_drift_guard.

neo_engine/main_loop.py — access pattern is top-level:

main_loop.py:219 — _asg_cfg = self._config.anchor_saturation_guard
main_loop.py:1481 — cfg = self._config.anchor_saturation_guard
main_loop.py:1594 — cfg = self._config.directional_drift_guard

No self._config.strategy.anchor_saturation_guard or self._config.strategy.directional_drift_guard references exist in the codebase.

config/config.yaml — top-level blocks:

line 158 — anchor_saturation_guard: (column 1)
line 183 — directional_drift_guard: (column 1)
line 203 — reconciler_conservative: (column 1)

None of these are nested under strategy:. Same structure in config.example.yaml, config_live_stage1.yaml, and config_live_session1.yaml.

Parser path — reads from top-level raw dict:

config.py:762 — asg_raw = raw.get("anchor_saturation_guard", {}) (not raw["strategy"]["anchor_saturation_guard"])
config.py:778 — ddg_raw = raw.get("directional_drift_guard", {})

Note on the tasking memo¶

Your tasking memo reads: "Add under strategy: in all three config files". This also does not match the current anchor/drift YAML layout (top-level in all config files). So the tasking memo and the ruling agree with each other but disagree with the code. I want to make sure the intent is clear before committing one pattern.

Two consistent options — please pick one¶

Option 1 — mirror actual anchor/drift precedent (top-level):

Add inventory_corridor_guard: InventoryCorridorGuardConfig as a top-level Config field alongside the other three guards.
YAML block at top level in all four config files, matching anchor_saturation_guard / directional_drift_guard location.
Access in main_loop.py as self._config.inventory_corridor_guard.
Zero breaking change to existing structure; matches the lived pattern for Phase 7.3 guards; minimal cognitive load for future readers who see three guards side-by-side.

Option 2 — new convention (nested under StrategyConfig) + migration:

Add inventory_corridor_guard: InventoryCorridorGuardConfig as a field on StrategyConfig.
YAML block nested under strategy: in all four config files.
Access in main_loop.py as self._config.strategy.inventory_corridor_guard.
To preserve your ruling's stated invariant ("the same as anchor_saturation_guard and directional_drift_guard"), this branch would need to also relocate anchor_saturation_guard and directional_drift_guard under StrategyConfig in the same change. That pulls two merged branches worth of history into this one and is a bigger scope than the tasking specified.
If Option 2 is intended but without relocating the existing two guards, the codebase will carry two placement conventions for Phase 7.3 guards. Flagging so the decision is explicit.

My recommendation¶

Option 1. Matches the code I can see, zero migration, matches the tasking's architectural intent ("same pattern as anchor and drift guards" interpreted as "mirror the actual implementation of anchor and drift guards"). I'll build this on green light.

If you meant Option 2, I'll also do that — please state whether the scope includes relocating the two existing guards, and I'll deliver in two commits instead of one for that C1.

Current Position¶

Still on fix/reconciler-disappeared-order-conservative — no branch created, no code written.
Ready to start C1 (config schema + YAML defaults) the moment you rule.
All other Q4/Q5/reset-pattern rulings already internalised — no further blockers after placement.

— Orion