Building An AI Candlestick Pattern Recognition Engine In Code: From Rule-Based Detectors To ML Overlays On The Chart

44 + 53 - Candlestick and chart patterns TradingView detects automatically; TrendSpider identifies over 100 across timeframes  ·  OHLC predicates - Classical patterns are boolean conditions on open, high, low and close - the foundation of any detector  ·  Candles → model → overlay - 2026 AI charting engines send candle data to ML endpoints and render predictions back as mark overlays  ·  Explainable first - Rule-based detection gives you fast, deterministic, explainable signals; ML adds adaptivity on top, never instead

Pattern recognition on charts has gone from a skill traders learned by eye to a feature every serious platform ships: TradingView automatically recognises 44 candlestick patterns and 53 chart price patterns across stocks, ETFs, forex and crypto; TrendSpider identifies over a hundred, along with trendlines and Fibonacci levels; and in 2026 a new generation of AI charting engines goes a step further, sending live candle data to machine-learning endpoints and rendering the resulting predictions directly onto the chart as overlays. To a user it looks like magic on a screen. To an engineering team that specialises in trading charts, as we do, it is a concrete and genuinely interesting build problem with real correctness stakes: how do you turn a stream of OHLC bars into reliable, fast, explainable pattern detections, and how do you layer machine learning on top without producing an engine that confidently marks hammers and engulfings that are not there? This playbook is a code-side tour of how a candlestick pattern recognition engine is actually built - from the boolean predicates that define the classical patterns, through the rule-based detection layer that should be your foundation, to the ML classifiers and the proxy-and-overlay architecture that add adaptive intelligence on top - and the discipline that keeps the whole thing honest.

Layer One: Patterns As Predicates On OHLC

The foundational insight is that every classical candlestick pattern is a boolean condition over a small window of OHLC bars, which makes the base layer of a pattern engine a set of pure functions rather than anything exotic. A single candle has an open, high, low and close; from those you derive the quantities the patterns are defined on - the real body (the distance between open and close), its direction (bullish if close is above open), the upper shadow (high minus the higher of open and close), the lower shadow (the lower of open and close minus low), and the total range. A doji is a candle whose body is tiny relative to its range; a hammer is a small body near the top of the range with a lower shadow at least some multiple of the body and little or no upper shadow; a bullish engulfing is a two-candle window where a bearish candle is followed by a bullish one whose body fully contains the prior body; a morning star is a three-candle sequence with a large bearish candle, a small-bodied candle gapping below, and a large bullish candle closing well into the first. Each of these is a predicate - a function from a window of bars to true or false - parameterised by thresholds (how small is 'tiny', how many times the body must the shadow be) that you make explicit and configurable rather than burying as magic numbers. Building the base layer this way gives you three properties that matter enormously downstream: it is deterministic, so the same bars always produce the same detections; it is fast, because evaluating a handful of arithmetic comparisons per bar is trivial even at high frequency; and it is explainable, because every detection can be justified by pointing at the exact rule and the exact bar values that satisfied it. This is why purpose-built libraries exist for exactly this layer - including a zero-dependency, no_std Rust crate for identifying Japanese candlestick patterns built precisely for algorithmic trading, backtesting engines and technical-analysis tools - and why you should treat this layer as the reliable foundation everything else stands on.

• Derive the primitives once - body, direction, upper shadow, lower shadow and range from each OHLC bar, and build every pattern on those.
• Express patterns as pure predicates - functions over a window of one to three-plus bars returning true or false, with thresholds as explicit parameters.
• Make thresholds configurable - what counts as a 'small body' or a 'long shadow' varies by instrument and timeframe; never hard-code them.
• Evaluate incrementally - as each new bar closes, evaluate the predicates over the trailing window rather than rescanning the series.
• Keep it deterministic and explainable - every detection must be reproducible from the bars and justifiable by the rule that fired.

Layer Two: Machine Learning On Top, Never Instead

Rule-based detection has a well-known limitation: real patterns form with variation that rigid thresholds either miss or over-match, and this is exactly where the 2026 AI charting engines add value - with machine-learning models trained on historical price data to recognise recurring structures and adapt to subtle variations in how a pattern forms. The engineering mistake is to think ML replaces the rule layer; the correct architecture is ML on top of it. A classifier - typically fed a normalised window of recent bars (and often derived features like body ratios, shadow ratios and relative volume) - produces a probability that a given structure is present, and it can catch a slightly irregular hammer the rigid rule rejected, or down-weight a textbook-looking engulfing that appears in a context where the model has learned it rarely matters. But a probability is not a detection, and treating it as one is how engines start hallucinating patterns. The disciplined design keeps the two layers distinct in the data model and in the UI: rule-based detections are facts (this pattern is present by this definition), ML outputs are predictions with a confidence score and a clear label saying so, and the engine never silently blends them. This also lets you evaluate each layer on its own terms - the rule layer against its definitions, the ML layer against a labelled historical set with precision and recall you can actually measure - which is the only way to know whether the adaptive layer is adding signal or adding noise.

The Proxy-And-Overlay Architecture

The way the new engines wire ML into a live chart is a clean and reusable architecture, and it is worth describing because it generalises well beyond candlesticks. The chart front end maintains the OHLC series and renders it; a proxy service sits between the chart and the model - the engine's ai-proxy-service pattern - receiving candle data from the chart, batching and normalising it, forwarding it to an ML endpoint (a TensorFlow or PyTorch serving instance, or any inference API), and returning the predictions; and the chart then renders those predictions as mark overlays - markers, shaded regions or annotations anchored to the specific bars they refer to. The proxy is the important design element: it decouples the chart from any particular model, so you can swap or A/B models without touching the front end; it is where you enforce rate limits, batching and caching so a fast-updating chart does not hammer the inference endpoint on every tick; and it is where you attach the provenance that keeps the UI honest - which model, which version, what confidence - so the overlay can label a prediction as a prediction. On the rendering side, the rules from real-time charting apply: overlays must be anchored to bar indices, not pixel positions, so they survive pan and zoom; they must update incrementally as new bars arrive rather than being redrawn wholesale; and they must be visually distinct from rule-based detections so a trader can tell a deterministic fact from a probabilistic model output at a glance. Get the proxy and the anchoring right and you have an engine that can render any model's output onto the chart safely; get them wrong and you have overlays that drift, flicker and mislead.

The Bottom Line

Automatic pattern recognition has become a standard charting feature - TradingView's 44 candlestick and 53 chart patterns, TrendSpider's hundred-plus, and 2026's AI charting engines that send candle data to ML endpoints and render predictions as overlays - but building it well is a real engineering problem with real correctness stakes. The right architecture has two distinct layers. The foundation is rule-based detection: classical patterns expressed as pure, parameterised boolean predicates over a window of OHLC bars, derived from body, shadows and range, evaluated incrementally as bars close - deterministic, fast and explainable, which is exactly why zero-dependency libraries exist for it. On top sits machine learning that adds adaptive recognition of irregular formations, producing labelled probabilistic predictions that are never silently blended with rule-based facts. The two are wired into a live chart through a proxy service that decouples the chart from the model, handles batching, caching and provenance, and returns predictions the chart renders as bar-anchored, incrementally-updated, visually-distinct overlays. Holding it all together is the discipline of a trading system: predicates tested against constructed bars, ML evaluated on labelled history with honest precision and recall, confidence thresholds, and a UI that never lets a prediction masquerade as a fact. That combination of fast, correct detection and honest presentation is exactly the specialism we bring to trading charts, and it is what separates an engine traders can trust from one that merely looks clever.

References & Further Reading

• TradingView - automatic candlestick pattern detection (44 candlestick and 53 chart patterns): https://www.tradingview.com/support/solutions/43000584462-automatic-candlestick-pattern-detection/
• BrightCoding - CandleView: the AI charting engine (ai-proxy-service to ML endpoints, markData overlays): https://www.blog.brightcoding.dev/2026/07/13/candleview-the-revolutionary-ai-charting-engine-every-trader-needs
• GitHub (l33tquant) - candlestick: zero-dependency no_std Rust candlestick pattern recognition library: https://github.com/l33tquant/candlestick
• Liberated Stock Trader - top 5 stock chart pattern recognition tools, full 2026 test (TrendSpider, TradingView, MetaStock): https://www.liberatedstocktrader.com/candlestick-pattern-analysis-recognition-software/
• ICCandle - why technical analysis is evolving: the rise of AI candlestick pattern recognition in 2026: https://iccandle.ai/en/resources/articles/why-technical-analysis-is-evolving-the-rise-of-ai-candlestick-pattern-recognition-in-2026