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)

PolicySim P&Lvs actual +$36kMultiplier
Actual (fixed +10% LMT)+$36,286baseline
Pure trail 5%+$451,580+$415,29412×
Pure trail 3%+$536,504+$500,21914×
Scale 50% at +10% LMT + trail 5% on rest+$305,457+$269,171
Scale 50% at +10% LMT + trail 3% on rest+$364,184+$327,89810×

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 pctValue
Median0.56%
P750.82%
P901.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:

  1. 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.

  2. 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.

  3. 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:

WhereVerdictReason
IBKR native TRAILING_STOP_MARKET❌ Not viableUnreliable on options at IBKR. Can’t combine with scale-out.
MK2 engine-sideRecommendedData 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⏳ FutureTrailingStopMarketOrder is first-class. Migrate the MK2 implementation here when MK3 ships.

Configuration spec (Phase 1)

  • TRAILING_ENABLED env flag, default false for safety. Flip to true to 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=false restores 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%)