Elliott wave indicator: record when a turning-point label became available
Separate the date of a chart extreme from the later moment when an indicator confirmed it.
Published: (UTC+3)
Русский · English · Deutsch · Español · Français · Italiano · 繁體中文 · 日本語 · 한국어
Some chart indicators identify a turning point only after later price bars have arrived. They may then place the label on the earlier extreme. When evaluating an Elliott wave indicator, record both times so a finished historical chart does not imply earlier knowledge.
Ask about the confirmation mechanism
Read the documentation for the specific indicator. A pivot detector that requires later price bars cannot confirm the pivot before those price bars exist. This is a conditional example of indicator behavior, not a wave hypothesis that every Elliott tool uses the same pivot algorithm or confirmation period.
Keep two timestamps
In an invented detector, a high at price bar 40 requires three later completed price bars for confirmation. The extreme belongs to price bar 40, while the confirmation is available only after price bar 43 completes. A label drawn back at price bar 40 should retain price bar 43 as its availability time in the evaluation record.
Distinguish updating from future knowledge
A label that changes during the current unfinished price bar and a label added retroactively to an old price bar are different behaviors. TradingView documents several forms of repainting. Ask which behavior occurs, whether alerts wait for confirmation, and whether the historical display preserves the actual timing.
Review without assuming tradability
Compare the saved observation available at price bar 40 with the result after price bar 43. An accurately located old high can still have been unavailable at the earlier time. A chart annotation is not proof that an order could have been placed at that price when the high occurred.
The label is drawn on price bar 40 but requires price bar 43 to finish. Which time belongs in an availability record?
Record the extreme at price bar 40 and availability after price bar 43 completes. The display location must not replace the confirmation time.
A bounded non-repainting contract
A bounded “non-repainting” claim needs fixed quotes, version, settings, window and confirmation rule. Save the output at bar close and replay identical inputs. A pivot plotted retrospectively at its high does not prove that it was known at that high.
Revised vendor history, another timeframe, changed settings or another window change the input. Test intrabar movement, delayed confirmation and scenario replacement separately. A stable confirmed label can still be an incorrect hypothesis; display stability does not validate the wave.
Alerts: events and saved conditions
Pine code defines alert events; the user creates a running alert in TradingView’s interface. The service saves a copy of the script, inputs, symbol and timeframe. Later chart changes do not update that running alert: create a new one for a new context. Alerts operate on realtime bars.
For C>110, bar 21 reaches the threshold intrabar but closes 109; a close-only condition should not fire. Bar 22 closes 111 and qualifies. Record extreme, confirmation, sending and delivery times separately. alert.freq_once_per_bar_close restricts invocation timing; it proves neither structure nor a trade fill.