# Hunting 'Ghost Positions': The F-160 Rule and Defensive Design in System State Reconciliation > Source: > Published: 2026-11-12 02:13:12+00:00 It was 1:15 AM, and the trading system was running its routine midnight checks. Suddenly, the logs lit up with a series of critical warnings. The `position_monitor` had detected active, highly leveraged positions on the exchange—specifically, a 75x leveraged `1000PEPEUSDT` long and a 20x leveraged `ETHUSDT` long. There was just one massive problem: our internal system had absolutely no record of opening them. In the high-stakes world of algorithmic crypto trading, these are known as "Ghost Positions." If left unchecked, our AI trading engine would assume these were its own trades and attempt to apply automated Take Profit/Stop Loss (TP/SL) logic. The result? Catastrophic, unauthorized interventions on trades the system didn't originate, potentially liquidating manual positions or triggering disastrous margin calls. This post-mortem explores how defensive state reconciliation and strict execution rules—specifically the F-160 Iron Rule—prevented a potential financial disaster, and the architectural philosophy that makes it possible. In algorithmic trading, we operate under the assumption that the internal state (our database) and the exchange state (the broker's reality) are perfectly synchronized. When the AI decides to open a trade, it sends an API request, records the `OPEN` state internally, and manages the lifecycle. However, in production environments, perfect synchronization is a myth. Exchange APIs experience latency, webhooks get dropped during network blips, and human operators occasionally log into the exchange's web UI to manually adjust hedges or take speculative shots. When these external factors occur, the exchange state diverges from the internal ledger. If the system blindly trusts the exchange state, it will inevitably act on data it doesn't fully understand. A "Ghost Position" is an active position on the exchange side that lacks a corresponding internal `OPEN` record in our algorithmic ledger. During a routine `RECONCILE` phase, our system compares the real-time exchange state against the internal ledger. Here is what the logs captured when the ghosts appeared: ``` 2026-11-11 01:15:54,636 [WARNING] position_monitor: RECONCILE: Unrecorded position 牛来USDT LONG@0.0839 (10x) — treating as manual (no OPEN record) 2026-11-11 01:15:54,637 [WARNING] position_monitor: RECONCILE: Unrecorded position ETHUSDT LONG@2240.05 (20x) — treating as manual (no OPEN record) 2026-11-11 01:15:54,637 [WARNING] position_monitor: RECONCILE: Unrecorded position 1000PEPEUSDT LONG@0.0047 (75x) — treating as manual (no OPEN record) ``` These positions could exist for several reasons: `OPEN` event. The danger is immediate. The AI's execution engine sees an open position and naturally attempts to manage it. If it applies its automated TP/SL logic to a manually opened 75x leveraged meme coin position, it could prematurely close a winning manual trade, or worse, execute conflicting orders that violate the exchange's margin requirements. To prevent catastrophic automated interventions, we rely on a two-pronged defensive mechanism: Defensive Reconciliation and the F-160 Execution Guardrail. The `position_monitor` logic is designed to be inherently suspicious. When it compares the real-time exchange state against the internal ledger and finds a discrepancy, it does not guess. It does not attempt to "adopt" the position into the algorithmic strategy. Instead, it applies a critical design choice: **flag the discrepancy as 'manual' with a safe default.** Flagging the position is only half the battle; we must also prevent the execution engine from acting on it. This is where the F-160 mechanism comes in. F-160 acts as a hard circuit breaker. When the system processes these flagged positions, F-160 explicitly checks if the position is in the approved manual list or if it has specific algorithmic markers (like `CAT_` conditional orders). If it lacks these, F-160 triggers: ``` 2026-11-11 01:15:54,637 [WARNING] position_monitor: F-160: ETHUSDT not in manual list and no CAT_ orders - treating as MANUAL (safe default) ``` Consequently, the execution engine applies the F-160 iron law, bypassing all automated TP/SL logic for these unregistered positions: ``` "error": "Manual position (unknown (F-160 safe default)) - skipped auto TP/SL per F-160 iron law" "error": "Manual position (known manual) - skipped auto TP/SL per F-160 iron law" ``` **The Result:** The AI trading system successfully maintains strict isolation between its own algorithmic strategies and external/manual market activities. The ghost positions are safely ignored by the automated engine, preserving system stability and preventing disastrous automated overrides. The F-160 rule is not just a standalone script; it is a manifestation of a deeper engineering principle: **State Isolation Architecture**. In our system, we strictly separate the *intent* of the algorithm from the *reality* of the exchange. This isolation is layered with other defensive mechanisms visible in our logs. For instance, when the system encounters technical anomalies or missing data, it doesn't crash or guess; it defaults to safe states. We see this in the scoring engine's elastic thresholds adapting to consecutive vetoes, and in the hard-veto mechanisms rejecting trades when multi-timeframe percentiles are misaligned: ``` 2026-11-11 01:15:52,326 [INFO] scoring_engine: F-229/F-230: Elastic threshold: 75 → 70 (consecutive_veto=239, original=80, floor=60) 2026-11-11 01:16:43,636 [INFO] adv_trend_direction: [F-ADV-PCTB-HARD-VETO] HYPEUSDT SHORT rejected: 15m,1h,4h pctb={'15m': 10.03, '1h': -15.12, '4h': -8.23} ``` By treating the internal ledger as the absolute authority for algorithmic actions, we ensure that the AI can never accidentally manage a trade it didn't conceptualize. Hunting ghost positions reinforces a fundamental truth in quantitative engineering: **robust state management and defensive guardrails are non-negotiable for production-grade systems.** When building AI trading infrastructure, it is tempting to optimize for "happy path" execution—assuming APIs will always respond, databases will always sync, and operators will never touch the manual UI. But production systems live in the "sad path." Designing for failure means implementing "fail-secure" mechanisms rather than just "fail-safe" ones. When the F-160 rule triggered, it didn't just fail safely by doing nothing; it actively secured the system against a specific class of catastrophic errors by enforcing strict state isolation. Building resilient algorithmic infrastructure requires anticipating these edge cases and hard-coding the boundaries of the AI's authority. Discover more about building resilient algorithmic infrastructure and production-grade trading systems at [https://kestrelquant.com](https://kestrelquant.com). **Defensive system design mitigates technical and systemic errors but cannot eliminate market risk.** Handling ghost positions prevents automated disasters, but manual or external positions still carry full market exposure. Algorithmic trading involves substantial risk of loss; never deploy capital you cannot afford to lose. The architectural patterns discussed in this article are for educational and engineering purposes and do not constitute financial advice. *Tags: `#algotrading` `#crypto` `#ai` `#buildinpublic`*