Chart Patterns Course – Chapter 9 of 10. The difference between a pattern enthusiast and a systems thinker is simple: one says “that looks like a setup,” the other asks “can I define it, scan it, test it, and survive the parts I did not think about?” This chapter is about making the jump from visual impression to operational rule set.

Detection Is Not Execution
The first mistake in pattern system design is treating detection and execution as the same problem. They are not. Detection asks whether a shape exists according to a set of rules. Execution asks whether, given that detection, you should trade now, how, and under which constraints. A scanner can be excellent at finding triangles and still be useless as a trading engine if the execution logic is naive.
Lo, Mamaysky, and Wang matter here for a second time because they show what real progress looks like: formal definitions. Once the shape is defined computationally, you can stop arguing over screenshots and start testing behaviour. But even then, you are only halfway done. The pattern exists is not the same statement as the trade is attractive.
How To Formalise A Pattern
A usable rule set needs geometry and state. Geometry includes pivot structure, slope, duration, and relative highs and lows. State includes trend context, volatility condition, participation, and the rule for confirmation. For example, a triangle might require at least three touches, contracting range, a prior trend, and a close outside the boundary. A double top might require two comparable highs, a confirmed swing low between them, and a break of that swing low to trigger the idea. The exact rules can vary, but the point is that they must exist.
if prior_trend_up and pivots_valid and range_contracting and close > upper_boundary:
signal = "triangle_breakout"
else:
signal = None
That logic is still only a start. You then need to specify stop logic, profit logic, time stop, entry order type, universe filter, and what happens when multiple signals overlap. Backtests become untrustworthy surprisingly fast once any of those details remain vague.
Scanners Need Filters Before Patterns
A good scanner filters liquidity, spread, price, average volume, and perhaps regime before it even looks for patterns. Otherwise it will happily find beautiful setups in instruments you should never trade. This is one of the reasons discretionary traders sometimes distrust quant work. They have seen systems that detect elegant structures in statistically filthy places. The answer is not to reject automation. It is to respect preconditions.
For a chart-pattern course, the operational lesson is that scanning logic should serve tradeability, not just detection accuracy. A scanner that finds hundreds of weak candidates creates false confidence and false labour. A smaller list of liquid, structurally valid, context-aligned setups is far more valuable.
Backtest Overfitting Is a Real Threat
If you test enough patterns, filters, and thresholds on the same dataset, one of them will look brilliant. That is not proof of edge. That is often proof that statistics can be flattered when left unsupervised. This is where data-snooping literature, White’s reality check, and work on the probability of backtest overfitting become essential guardrails. The best-looking equity curve in-sample is often the most dangerous object in the room.
The antidotes are old-fashioned and effective: out-of-sample testing, walk-forward validation, realistic costs, and restraint in the number of variants explored. A backtest should not be allowed to audition endlessly until it finds the exact rule combination that history happened to reward.
Execution Assumptions Matter More Than People Admit
Best-execution guidance from FINRA and investor education from the SEC are useful here even if you are not building institutional routing systems. They force you to recognise that execution quality is a variable, not a rounding error. A breakout strategy using market orders behaves differently from the same strategy using limit orders. The difference is not cosmetic. It changes fill probability, slippage, missed opportunity, and realised expectancy.
If your backtest says every breakout was filled at the level with no delay and no slippage, you are not testing the strategy. You are testing your affection for fiction. Execution assumptions belong in the rules, not in a footnote after the results table.
What To Report From A Pattern Test
A serious chart-pattern backtest should report more than CAGR and win rate. It should include expectancy, max drawdown, turnover, holding period, average adverse excursion, average favourable excursion, exposure, capacity concerns, and performance by regime. If a pattern only works during one volatility state, that is not a flaw. It is information. But you only get that information if you ask better questions than “green line up?”
Why Rule-Based Work Improves Discretion Too
Even discretionary traders benefit from this chapter because rule-writing exposes vague thinking. Once you try to formalise your favourite setup, you quickly discover which parts were truly repeatable and which parts were just confidence with nice lighting. In that sense, backtesting is not only a profit exercise. It is an honesty exercise.
From Rules Back To Discretion
There is an irony here that good traders eventually appreciate. The more carefully you formalise a pattern setup, the better your discretionary judgement often becomes. Once you know exactly what the clean version looks like, you become much better at spotting when the live market is giving you a degraded imitation. That is why writing rules is not a betrayal of discretionary skill. It is one of the best ways to refine it.
That is also why a scanner should never be judged only by how many setups it finds. The better question is whether it helps you reject weak trades faster and define strong trades more consistently. In real pattern trading, filtering is often more valuable than discovery.
Summary Takeaway
Turning chart patterns into rules means defining the geometry, the trigger, the filter, the costs, and the execution path explicitly. A pattern is only testable and tradable when detection and execution are both specified with discipline.
Course Navigation
Previous: Chart Pattern Evidence and Success Rates: What the Research Actually Says
Next: A Professional Chart Patterns Playbook: Checklist, Review, and Deployment
Full course: Chart Patterns Course – Evidence, Execution, and Risk
This chapter is part of the Chart Patterns Course.
