Lookahead and repainting — verify when a signal became knowable

Separate changing realtime values, unconfirmed higher-timeframe data, past plotting, and future leakage. Test when a signal first became available, not just where its marker appears.

Published May 26, 2026 · Content updated October 1, 2026

Record the bar carrying the marker and the moment you could first have known about it as two separate facts.

Repainting broadly describes differences between historical and realtime calculation or display. An RSI or moving average changing on an open bar is one example. Not every such change is an error or deception. The practical question is whether the information available at the time matches the entry rule the user believes they are following. TradingView's repainting definition

Lookahead bias is the narrower error of using future information in an earlier decision. A signal that appears briefly, a pivot marked on an older bar after later confirmation, and a calculation that reads a future final value are different cases. They do not all have the same remedy.

Neither a high win rate nor a neatly placed arrow proves correctness or leakage. Trace when each value becomes confirmed and when the signal and order use it. The conditions in this article explain mechanisms; they are not a verified profitable strategy or a record of completed trades.

A changing open bar is not the same as future information

An open bar's high, low, and latest price can change before it closes. A crossover calculated from those values may briefly become true and then false. Reading the current price at that moment is not itself future leakage, although the final OHLC bar will not preserve every intermediate state.

Indicators generally recalculate on realtime price updates. Strategies calculate at the close by default; the calc_on_every_tick strategy option changes their realtime behavior. That option is not a shared indicator setting. Do not assume that close-only historical data fully reproduces an intrabar strategy. Execution and bar states

For rules requiring a confirmed chart-bar signal, check the use of barstate.isconfirmed. This concerns the chart bar's close. It does not confirm data requested from another timeframe or repair values plotted into the past. Intrabar rules can be intentional, but they require their own forward records and evaluation criteria.

Example 1 · Current price and confirmed chart close (Pine v6)

There are no inputs. On a standard 5-minute chart, compare the amber Current close line with the emerald Confirmed close dots. The current line follows updates on the open bar; the dots are designed to appear on the chart bar's closing update. Historical bars are confirmed, so both values agree there. Intermediate changes require records of actual updates.

//@version=6
indicator("OptiNod - Open bar and confirmed close", overlay=true)
// Layout: Minimal Overlay. Educational indicator; no orders or alerts.
float confirmedClose = barstate.isconfirmed ? close : na
plot(close, "Current close", color=#f59e0b, linewidth=2)
plot(confirmedClose, "Confirmed close", color=#10b981, linewidth=2, style=plot.style_circles)

Evaluate lookahead with the requested timeframe and expression

On a lower-timeframe chart, putting an unfinished higher-timeframe bar's eventual final value on earlier historical bars leaks information. A week's final high cannot be known on Monday before that high occurs. The timing establishes the problem without needing an unverified historical price anecdote.

Finding the name lookahead_on is not enough to classify every request as wrong. An unoffset expression from the current higher-timeframe bar differs from a request for an already completed higher-timeframe bar. Same-timeframe and lower-timeframe requests also require their own analysis. Other timeframe data and lookahead

The default lookahead_off does not guarantee confirmed HTF values in realtime. Historical placement and the developing realtime value can differ. To investigate consistency after a restart, examine the requested timeframe and confirmation time as well as the option.

Confirmed HTF requests combine a previous value with its placement rule

For confirmed higher-timeframe data, the official documentation describes using the previous requested-bar expression, expression[1], together with barmerge.lookahead_on. The offset belongs to the expression evaluated in the requested timeframe. Shifting the returned lower-timeframe series by one chart bar is not equivalent. Avoiding repainting in HTF requests

The technique discussed here requires a requested timeframe strictly higher than the chart timeframe. Equal or lower inputs need separate handling or rejection. Using the completed HTF bar means giving up reactions to the current developing HTF bar. It does not promise better performance or remove every other source of repainting.

Adding barstate.isconfirmed to the chart's entry condition does not confirm the HTF value. Putting it inside request.security() is not a substitute either. Design chart-bar confirmation and requested-bar confirmation separately. The limits of barstate.isconfirmed

Example 2 · Previous confirmed HTF close (Pine v6)

Use a standard 5-minute chart with the higher-timeframe input set to 60. The emerald step line is designed to use the previous 1-hour close from the beginning of each new 1-hour interval. [1] applies inside the requested 1-hour context; lookahead_on places an already confirmed value at the interval's start. It does not read the future close of the current hour. Equal or lower timeframe inputs are rejected. You give up the current hour's latest movement; this does not address feed revisions or past plotting elsewhere in a script.

//@version=6
indicator("OptiNod - Previous confirmed HTF close", overlay=true)
// Layout: Minimal Overlay. Educational indicator; no orders or alerts.
string higherTimeframe = input.timeframe("60", "상위 시간대", tooltip="차트보다 큰 시간대만 사용합니다. 5분 차트에서는 60분을 선택합니다.")
if timeframe.in_seconds(higherTimeframe) <= timeframe.in_seconds()
    runtime.error("Choose a timeframe strictly higher than the chart.")
float confirmedHigherClose = request.security(syminfo.tickerid, higherTimeframe, close[1], gaps=barmerge.gaps_off, lookahead=barmerge.lookahead_on)
plot(confirmedHigherClose, "Previous confirmed HTF close", color=#10b981, linewidth=2, style=plot.style_stepline)

Observed results and scope — Both Pine v6 examples compiled in TradingView Pine Editor and ran on a chart. During a short realtime observation of standard OANDA:EURUSD 5-minute candles, Example 1 showed a current price of 1.12886 while the confirmed chart close was not yet displayed. In a separate execution of Example 2, the current 5-minute price was 1.12892 and the previous confirmed 1-hour close was 1.12912; the emerald step line also appeared on historical chart bars. On a closed historical AAPL daily bar, both values in Example 1 were 333.02. These are observed values, not trade conditions or fixed inputs.

The checks cover chart execution and a brief realtime observation. They did not continuously track an entire 5-minute bar or both sides of an hourly boundary, so they establish neither restart consistency nor behavior across all markets. The next check is to fix the source, inputs, market and data range, record actual bar closes and HTF boundaries, and compare those records with a rerun.

A pivot plotted in the past was not necessarily known there

For a pivot requiring two bars to its right, the candidate bar and the later confirmation bar are different. Moving a marker back two bars can make the structure easier to see, but does not mean entry was possible at the candidate time. An order using that pivot must be evaluated after the pivot can be detected.

The last segment of a ZigZag or retracement levels based on a developing swing can also change before confirmation. The confirmation rule depends on the implementation. Claiming that an actual asset's peak became confirmed on a particular later date requires the settings and contemporaneous records. A tool's name or a high win rate cannot settle the question.

A negative plot offset moves a drawing backward; it is not an operation that reads future data. Pine's history-reference operator accesses past bars. An invalid negative history reference should not be presented as valid syntax for reading a future price. Inspect drawing coordinates and information availability separately. History-reference operator

Check alerts and executions separately from chart markers

If the intended rule uses the closing bar, its alert behavior should match. However, the frequency of alert() calls, settings for alertcondition() alerts, and strategy order-fill alerts are different mechanisms. A “Once Per Bar Close” choice does not apply identically to every alert type. Check the source and inputs used by the running alert as well. TradingView alerts documentation

An alert at the chart bar's close can still depend on an unfinished HTF value. Frequency settings do not replace a data-confirmation policy. A sent alert also does not establish that an order was accepted or filled.

A simulated fill at the signal bar's close does not automatically establish lookahead bias. Inspect the strategy's order type and fill options first. Whether that simulation represents actual delivery time and available prices is a separate check in the backtest versus live guide.

Reload comparisons need matching data conditions

Historical data can change through provider revisions, corporate-action adjustments, or a different starting point in loaded history. Assuming a closed bar can never change can misdirect the investigation toward code alone. Match source version, inputs, exchange, contract, standard candles, timeframe, session, and data range. Dataset variations and repainting

Confirmation-time observation — Choose standard 5-minute candles and a 1-hour HTF, then observe actual updates around the hourly boundary. A signal becomes eligible for an entry decision only after the previously specified confirmation rule passes. This observation sends no orders. Stop and invalidate the comparison if realtime recording is unavailable or the source, settings, or data conditions change.

During forward observation, record the clock time and timezone, chart-bar time, HTF interval, values, signals, and their first displayed locations. Check again after the close and after reloading. Recordings, screenshots, and alert logs can complement one another, but alert logs alone cannot recover all intrabar states that never triggered an alert.

Review observable behavior instead of using a win-rate threshold

• Developing realtime values, confirmed chart-bar values, and confirmed HTF values are distinguished.
• The HTF expression, offset, lookahead setting, and timeframe restriction are checked together.
• Pivot or ZigZag display bars are recorded separately from detection bars.
• Alert type, frequency, and running configuration are distinguished from executions.
• Forward observations under fixed source and data conditions are compared with a reload.

Bar Replay can help inspect historical sequences and delayed plotting. A Strategy Tester CSV records the trades of that simulation. Together they still cannot prove every contemporaneous realtime tick and signal. An example that has not been compiled, run on a TradingView chart, and observed in realtime should not be treated as verified code. Use records that explain when a signal appeared and which information produced it, rather than a “non-repainting” label or a particular win rate as the acceptance test.