When I started building my trailing-stop engine, I assumed the hard part would be the model.
It wasn’t.
The hard part was making the workflow reliable: timestamps, regimes, state synchronization, and a stop lifecycle that never “forgets” what it already knows.
What the Random Forest learned (and what it didn’t)
The model did not learn a single rule like:
“Put the stop 1.5×ATR below the low.”
Instead, it learned conditional risk tolerance:
“Given this trade state and market context, how much adverse movement is still statistically survivable before expectancy collapses?”
That means the RF isn’t a stop generator. It’s a risk gate.
The key shift: the model predicts a risk gate, not a stop price
In live trading, the engine proposes multiple candidate stop levels (structure stop, ATR stop, trailing stop, etc.).
For each candidate, the RF answers:
“If price retraces to this level, is the trade still statistically valid?”
Candidates that are too tight for current conditions fail the gate.
How the stop is chosen
- Generate candidate stop prices
- Evaluate each candidate through the RF risk gate
- Choose the tightest stop that still passes
The mental model I keep:
Rules propose. The forest disposes.
Why workflow correctness mattered more than the model
When timestamps or regime labels are wrong, the model looks wrong.
Once the workflow is correct, the model becomes consistent: it prevents stop tightening when conditions historically require more room, and allows aggressive trailing when conditions support it.
What I’m building next
- Diagnostics: “why did the model veto this stop?”
- Regime-specific performance breakdowns
- Workflow drift detection (timestamp/state/feature sanity)