Trailing-stop corpus validation - reverses prior “no trailing” decision
Context. 2026-05-14 mid-afternoon, after the time-of-day analysis surfaced TP-fill leakage (55% of trades with mid-MFE ≥+10% never registered as TP-hit), user asked for trailing-stop simulation. Ran two policies (pure trailing, scale-50/trail-rest) across multiple trail percentages, against both mid-MFE (best-case) and bid-MFE (realistic-execution). Result: trail mode dominates the current single-shot fixed +10% TP by 4-14× across the 22-day, 293-trade corpus. This finding directly contradicts and reverses the prior memory rule feedback_no_hwm_trailing_language.
Headline numbers (bid-MFE, realistic-execution sim)
| Policy | Sim P&L | vs actual +$36k | Multiplier |
|---|---|---|---|
| Actual (fixed +10% LMT) | +$36,286 | baseline | 1× |
| Pure trail 5% | +$451,580 | +$415,294 | 12× |
| Pure trail 3% | +$536,504 | +$500,219 | 14× |
| Scale 50% at +10% LMT + trail 5% on rest | +$305,457 | +$269,171 | 8× |
| Scale 50% at +10% LMT + trail 3% on rest | +$364,184 | +$327,898 | 10× |
Even with another 50% real-world haircut for queue position, partial fills, and IBKR sandbox flakiness, the scale-out + trail-5% config = +6k/day improvement, sustained.
Bid-vs-mid spread validation
Coverage: 3,498,964 / 3,822,947 path snapshots (92%) have bid data populated.
| Gap (mid - bid) MFE pct | Value |
|---|---|
| Median | 0.56% |
| P75 | 0.82% |
| P90 | 1.44% |
| Max (illiquid outlier) | 42.54% |
The mid-vs-bid spread on this engine’s option choices is much tighter than feared. The median 0.5% gap means MFE measured at mid is a close proxy for what we could actually sell at. Even on the extreme winner (trade #259, +110% MFE): mid +110.6% vs bid +109.8%. Liquid market behavior.
Why fixed +10% TP fails on this engine
Three populations exposed by MFE analysis:
-
TP-LMT fill leakage (125 of 228 non-TP trades). Mid touched +10% but the LMT didn’t fill at the broker (queue position, timing, or partial fill on the wrong side of the spread). Lost ~10k true loss), the remaining ~100 are order-mechanic issues.
-
Massive overshoot winners (104 trades, MFE ≥15%). Option premium ran 15-100%+ above entry. We capped at +10%. Cumulative MFE-above-TP for this cohort is ~$300k+ - most of the trail’s edge comes from capturing some fraction of these.
-
Round-trip catastrophes (trades #34, #246, #273, #279). MFE went +50-80%, then reversed through entry and hit -25% PRICE_STOP. Trail with 5% give-back would have exited near MFE on the way down, locking +45-75% gain instead of -25% loss. Six-figure swing on a single trade in some cases.
Architecture decision: build in MK2 NOW
User’s constraint: MK3 (Nautilus) is weeks-to-months out and this is a paper-trading window for data collection. The value of running trail-mode for the next 2-8 weeks of paper outweighs the cost of a focused MK2 implementation.
Three implementation paths considered:
| Where | Verdict | Reason |
|---|---|---|
IBKR native TRAILING_STOP_MARKET | ❌ Not viable | Unreliable on options at IBKR. Can’t combine with scale-out. |
| MK2 engine-side | ✅ Recommended | Data model partially exists (position_state.high_water_mark, trailing_* columns). Tick-driven exit plumbing exists (PRICE_STOP). ~2-3 days Codex work. |
| MK3 / Nautilus native | ⏳ Future | TrailingStopMarketOrder is first-class. Migrate the MK2 implementation here when MK3 ships. |
Configuration spec (Phase 1)
TRAILING_ENABLEDenv flag, defaultfalsefor safety. Flip totrueto enable.TRAIL_PCT = 0.05- give-back behind HWM that triggers trail exit.SCALE_OUT_PCT = 0.5- fraction of position to exit at clean +10% LMT.TRAIL_ENGAGEMENT_PCT = 0.05- option mid must reach +5% above entry before HWM tracking starts (avoid early-trade noise triggering trail).- Fallback: setting
TRAILING_ENABLED=falserestores current single-shot +10% LMT behavior. Easy revert.
What this reverses
The prior memory rule feedback_no_hwm_trailing_language stated:
Single-shot +10% fixed TP, no trailing. HWM is telemetry only; don’t frame analysis around it.
That decision was made before the corpus had enough trades to validate it empirically. The 293-trade, 22-day corpus now decisively contradicts it. The HWM column was already being tracked as telemetry; it’s just been waiting for the data to support enabling its use.
The Nautilus brain page (nautilus-orders.md) also notes:
NOT for V1. The mandate is feedback_no_hwm_trailing_language. V2+ might use it if the trend-day-detection work matures.
That note can now be updated: corpus data justifies V2+ promotion ahead of schedule.
Confidence and risk
High confidence: the direction (trail > fixed TP) on this corpus is decisive across every variant tested.
Medium-high confidence: magnitude. Sim says +100-200k. Still 3-6× over current.
Real risk: outlier-day exposure. The 2026-05-05 day (+$74k actual, mostly from clean +10% TP fills on a perfect-trend day) underperforms in trail mode. If we get a stretch of trend days, the edge shrinks. Quantifiable from shadow-mode data.
Mitigations baked into config:
- Env flag for instant revert
- Trail engagement threshold (don’t trigger on noise)
- Scale-out preserves clean TP captures for the trend-day case (half locks at +10%)
Memory links
- 2026-05-14-impulse-vs-composite-empirical-tier-analysis
- 2026-05-14-sl-and-peak-stop-corpus-validation
- 2026-05-14-time-of-day-day-of-week-corpus-analysis
- 2026-05-14-five-corpus-rules-for-mk3
- feedback_no_hwm_trailing_language - being reversed
- project_runner_ladder - related runner-ladder concept
- nautilus-orders - needs update on V2+ trail timing
- Task #104 - P0 MK2 trail implementation