Pattern recognition: where manual chart labeling breaks
Pattern recognition breaks exactly where manual chart labeling begins. Head and shoulders, triangle, and wedge are geometry that an analyst draws on candles by hand, and next time they will draw it slightly differently.
The neckline shifts by a couple of candles — and the pattern is formally unconfirmed, even though the market played out exactly that pattern.
Over a history of several hundred episodes, the divergence accumulates. Two labelers produce different samples, the same configuration ends up either in the training set or in the validation set, and comparison of hypotheses loses meaning — there is nothing left to compare.
The flip side is even more costly: while pattern boundaries are refined by eye, trading signal latency grows, and an entry on a triangle happens when the move has already played out.
Night sessions and rare instruments add their own — an episode is missed, and pattern statistics are biased toward the hours when the analyst was at the monitor.
The reason is not the labeler's qualification, but the absence of formalized criteria: where pattern formation ends, what amplitude we consider significant, how many candles confirm a breakout, and what we consider its invalidation.
Without these rules, pattern recognition remains expert opinion that can neither be reproduced nor validated on history. Next we break down how this is closed by moving pattern logic into code and what exactly catches false positives.
What changes in a trading system after automating pattern analysis
Manual labeling hits human limits: two analysts on the same history set the boundaries of a "head and shoulders", triangle, or wedge differently.
On a quarter of history for a dozen instruments, this is days of work, and discrepancies surface late — when decisions on an instrument have already diverged.
Automation turns a pattern into a set of testable conditions: position of local extrema, slope and touches of trendlines, volume confirmation. State is tracked explicitly — forming, confirmed, broken — so the signal does not depend on who looked at the chart.
A separate validation layer discards a candidate if the window contains a gap or missing quotes: such joins assembled a pattern from non-adjacent bars and produced the worst class of false entries.
What this changes according to our measurements:
| Metric | Manual analysis | Automated |
|---|---|---|
| Analysis of a quarter of history | days of analyst work | single run across the entire sample |
| Pattern boundaries across analysts | diverge | unified rules, divergence within tolerance |
| Missed pattern | depends on workload | history processed in full |
| Quote gap or missing data | pattern glued from non-adjacent bars | window flagged, pattern not built |
Quality control rests on a reference set — several hundred manually labeled patterns, including disputed ones.
A run after each rule change shows separately the false positive rate and separately the missed rate: an attempt to suppress one metric at the expense of the other is immediately visible.
Some geometric primitives are taken from the open library TA-Lib; the logic of the patterns and confirmations we describe ourselves — it can be modified for a specific market.
Analysis stops being time-limited, and labeling becomes reproducible: the same run on the same data gives the same result.
How pattern recognition is structured: three approaches to pattern detection
A pattern can be formalized in three ways, and each has its own cost of error.
A hard rule describes shape via detected extrema, trendline slope, and touch tolerance in volatility fractions; training on labeled history searches for the same shape by window features; a hybrid leaves rough selection to rules and confirmation of disputed cases to the analyst.
The choice depends on instrument liquidity, horizon, and which error class is acceptable in the decision.
| Approach | When suitable | Limitations |
|---|---|---|
| Hard geometric rules | Liquid instruments, higher horizons, need explainability of each signal | Tolerances selected manually, rule breaks when volatility changes, many false positives in a sideways market |
| Training on labeled history | Lots of homogeneous data, need noise robustness | Quality depends on labeling, classes imbalanced, behavior drifts when regime changes |
| Hybrid with manual validation | Decisions are made from signals, error is costly | Part of validation remains with the analyst, response slower than automated |
The common weakness of all three is labeling historical data.
If pattern boundaries in training are set using already known future price continuation, quality on history looks high, but on new data the model falls apart: validation must be on a rolling window, training only on the past.
The hybrid addresses this with manual validation of disputed cases, but pattern detection rules are still fixed before training.
Work stages: from data audit to handover of the configured system
We work in iterations: first we fix what exactly we consider a pattern on historical data, then we build reproducible detection, and only then we tune thresholds.
This order removes fitting to a specific chart segment — the detector is validated on data it did not see during tuning.
- Audit of historical data and requirements. We check quote completeness, gaps, splits and stitching, time zones, and agree on the pattern list ("head and shoulders", triangles, wedges), timeframes, and what we consider pattern confirmation.
- Pattern feature schema. We formalize the geometry: number of trendline touches, slope, symmetry of shoulders, retracement depth, volume behavior on breakout. Without a written schema, features turn into subjective taste and are not reproducible.
- Pattern detection setup. We implement the detector: series smoothing, local extrema search, line approximation, geometry validation. The output is labeling with boundary coordinates and a confidence score for each pattern.
- Validation on a holdout period. We run the detector on data not involved in tuning, calculate precision and recall, and analyze discrepancies with analyst labeling. This separates real pattern recognition from memorizing history.
- Threshold calibration. We tune tolerances for slope, length, and volume so as to remove false positives without losing rare patterns. Final values are fixed in configuration, not code.
- Handover and team training. We hand over labeling, configuration, and instructions for adding new patterns, and show which metrics to monitor so detection quality does not degrade after changes.
Deliverables: labeling rules, schemas, update policies
Pattern labeling and detection parameters must not live in the developer's head or in chat: at the first signal discrepancy, it is unclear who is right.
Therefore, along with the system, the client receives artifacts by which it can be operated, validated, and handed to another team.
- Labeling rules — criteria for a completed pattern: how many candles form the top and shoulders, allowable asymmetry, how gaps and news impulses are interpreted. The labeler and the algorithm follow one document, so discrepancy is visible immediately.
- Feature schema — table "feature → source → calculation window → weight in decision": trendline slope, retracement depth, volume on breakout. A new feature is added without breaking already tuned ones.
- Pattern detection configuration — tolerance thresholds, minimum amplitude, confirmation window, duplicate suppression rules. Thresholds are moved out of code: they are edited without rebuilding the service.
- Retraining and threshold review policy — on which sample and with what frequency we verify labeling, which metrics we consider degradation, and who approves a configuration change.
- Validation log — control sets with manual labeling and run history: you can see after which change precision dropped and which threshold set performed better.
- System documentation — instructions for the team: how to bring up the recognition service, where to view rejected signals, how to roll back configuration to the previous one.
- Ownership map — who is responsible for labeling, who for features, who for pattern detection: without it, artifacts become outdated within a quarter.
Trading platform project case study: labeling before and after
Pattern labeling lived in a spreadsheet: analysts manually marked "head and shoulders", triangles, and wedges, each label with chart timeframe, bar range, and comment.
We ran discrepancy measurement on the same segments and got a number audiences usually dislike: independent labelers agree only in 71% of cases, and rare formations — expanding triangle, contracting wedge — were found by one analyst out of four.
A signal on a confirmed pattern reached the trading pipeline tens of seconds after bar close: part of the move had already played out by then.
What we changed substantially
We stopped describing a pattern with a picture — it became a set of formal conditions: number of trendline touches, slope, allowable price deviation from the boundary, minimum retracement depth, mandatory confirmation bar.
Analyst labeling was moved to Label Studio and tied to chart timeframe, and disputed episodes were moved to a separate reconciliation queue so they would not dissolve in the overall sample.
Metrics before and after
- Agreement of labeling between analysts: 71% → 94%.
- Share of disputed labeled episodes: 19% → 4%.
- Recall of rare pattern detection: 0.4 → 0.9.
- Signal delay after confirmation: tens of seconds → a few seconds.
- False positives on noise: decreased threefold at the same confirmation threshold.
What had to be refined along the way
The first version of the rules did not distinguish wedge and triangle at the range boundary: formations with two touches went into one label.
We added a neckline shape feature and a minimum number of touches requirement — disputed episodes decreased, but some wide formations fell out of detection, and the threshold had to be recalibrated on historical data.
Separately, we fixed the discrepancy between labeling on different timeframes: analysts date the same pattern differently on daily and weekly charts, so the label was tied to the timeframe on which the pattern is confirmed.
What to do if patterns are already labeled manually?
Manual labeling of historical patterns is not garbage but a ready training set: it captures your market interpretation, which cannot be reconstructed from quotes. The question is not whether to trust it, but whether the criteria are consistent among those who labeled.
If labeling was collected over years by different people, labeling quality is the first thing checked before any additional training.
We calculate agreement for each pattern type separately: whether boundaries, confirmation point, and minimum amplitude match. Where the agreement share is low, it is not model noise but a disputed rule — it is agreed upon before training.
Then a random sample audit: disputed fragments are sent for relabeling to two independent labelers, discrepancies go to arbitration by rule, not by voting. This makes quality measurable rather than "by eye".
Labeling conflicts are almost always of three types: one pattern labeled with different boundaries, one chart segment marked as both triangle and wedge, or patterns overlap in time.
Each conflict is classified and closed by a decision that is recorded in a versioned labeling schema — otherwise the same discrepancies return in the next iteration.
Additional training on your data is done on top of the base model, not from scratch, and with sample split by market periods: otherwise the system learns one regime and falls apart when volatility changes. Pattern analysis rules remain the source of truth, while the model expands recognition coverage.
Rule transfer is checked with a regression set: old labeled patterns are run before and after additional training. The agreement share must not fall — new classes must not "eat" previous ones.
If it falls, the rule outweighs the model: labeling is exported from the TradingView terminal, and discrepancy with it is visible on the first runs.
Technical concerns: noise, false patterns, fault tolerance
On live data, pattern detection encounters quote gaps, incomplete candles, and ambiguous labeling. Below are five questions that most often come up at acceptance, and how we address each.
How does the system handle noise on lower timeframes?
We suppress noise on the chart at the input: series smoothing, pattern amplitude threshold, volume confirmation. Some early signals are filtered out — thresholds are kept in configuration and tuned for a specific instrument, not hardcoded.
Patterns are rare — what about triangles and wedges?
Rare formations — triangles, wedges, head and shoulders — are evaluated not individually but as families of similar configurations. This builds enough statistics for an honest accuracy estimate rather than fitting to isolated cases.
What guarantees the model isn't overfitted?
We validate on a holdout history segment not involved in tuning, and run rules sequentially over time. A noticeable gap between tuning and validation accuracy is a direct sign of overfitting; such a configuration is sent back for revision.
What happens during data feed gaps?
Data feed gaps are logged as a separate event: history is backfilled, and a signal for which there weren't enough quotes is marked unconfirmed — the system doesn't silently complete candles. After feed restoration, labeling is recalculated on the full series.
What does post-implementation support include?
Post-implementation support includes updating thresholds for volatility regime changes, monitoring the false positive rate, and editing labeling rules. Feed access and configuration change procedure are documented in a policy so the system doesn't end up without an owner.
Let's discuss your task: data, patterns, signal requirements
For the estimate and work plan to rely on your data rather than average assumptions, answers on three axes are enough for the discussion: price history, pattern labeling, and signal requirements. Below is what exactly we clarify and how each item changes the scope of work.
- Data and history. Instruments and timeframes, source (exchange, broker, own archive), depth in candles, gaps and breaks between sessions, contract rollover rules.
- Pattern labeling. What is mandatory: head and shoulders in two variants, triangles, wedges. With tolerances — minimum pattern height and width, number of line touches, slope angle.
- Confirmation criterion. Breakout of the neckline or boundary with a close beyond it, return of price to the broken level, volume confirmation. Signal delay relative to the moment of pattern formation depends on this.
- Quality requirements. Acceptable false positive rate, behavior on incomplete patterns and on low-liquidity instruments.
- Signal delivery. Message queue, table write, or external service call; message format, latency, whether a log with trigger history is needed.
- Implementation and acceptance procedure. On what historical segment we validate accuracy, who on your side accepts the result, whether a test environment with a real-time data feed is needed.
If some data is missing, it doesn't block the start: we'll suggest what to substitute and how to assemble history for your case. Describe the task in free form — we'll return with an estimate and work plan where stages and checkpoints are fixed.