Look-ahead bias occurs when a historical test uses information that was not available at the time its simulated decision or order would have happened. The rule can be simple and the code can run without errors while the result still relies on future information. A useful audit asks, for every input: when was this value first knowable, when did the rule evaluate it, and what later price was used for the simulated action?

chronological research windowsA chronological test splits historical data so future evaluation bars do not participate in choosing earlier parameters; later information can still affect repeated researcher decisions.Earlier observationsSpecify; estimate parameters hereHoldoutEvaluate onceLaterForward reviewOldestTime →A holdout reduces one form of reuse; it cannot erase repeated research choices or guarantee future performance
A chronological test splits historical data so future evaluation bars do not participate in choosing earlier parameters; later information can still affect repeated researcher decisions. Illustrative teaching diagram · not live market data

A candle’s close is known only after it finishes

Each OHLC bar summarizes an interval. Its final high, low, close and volume are not complete at the bar’s open. If a breakout rule depends on the completed close of a one-hour candle, the test should not enter at that same candle’s earlier open. A causal example evaluates the close when the bar is complete and models a decision or entry at a later available price, such as the next bar’s open—with that convention clearly labeled as a model. For code-specific timing, TradingView’s Pine Script bar-state and time documentation distinguishes confirmed bars from a developing realtime bar; those language details do not prove that an exchange order would fill at the next open.

Do not assume that a next-bar open is a guaranteed fill either. A gap can cross the level, the spread may be material, the order can be rejected or partially filled, and the true order book may be unknown. Correcting the information timing removes one bias; it does not create realistic execution evidence.

Worked example: a higher-timeframe value arrives later

Suppose a one-hour study uses a four-hour close and tests the rule “act when the four-hour close is above $100.” A four-hour bar starts at 08:00 UTC. The last confirmed four-hour close is $98; the current bar eventually closes at $104 at 12:00. The final $104 was not knowable at 09:00, yet a historical request.security() call using barmerge.lookahead_on without offset can place that final value on the first hourly bars inside the four-hour window. A backtest may therefore show the condition passing before noon. In live data, the current four-hour close is still forming; it can move above and below $100 before it is confirmed. TradingView documents both this historical future leak and the confirmed-value pattern using a one-bar offset with lookahead_on. That pattern deliberately uses the previous completed four-hour value; it does not make the current bar’s final close available early.

For this example, $98 remains the confirmed input through the 08:00–12:00 interval. If the rule instead waits for the completed $104 close, timestamp the decision at or after 12:00 and model the order at the next eligible price. TradingView’s broker emulator uses its own historical fill assumptions, including a next-tick convention by default; neither that convention nor a clean chart guarantees a real venue fill. The dates and prices above are fictional and only demonstrate information timing.

look-ahead information and later entry timelineA completed-bar rule cannot know the final close at that bar's open. The red same-bar entry would precede the information used to trigger it; the green modeled action occurs only after the signal is known and must still be treated as an execution assumption.ASK WHAT WAS KNOWN AT THE EXACT DECISION TIMEBar N · formingopen known · final closenot known yetBar N · confirmedsignal can now becalculatedopenclosenext available priceinvalid timing: same-bar open before close-based signalcausal model: signal first, later action secondA later-bar price is still a model assumption, not a guaranteed fill
A completed-bar rule cannot know the final close at that bar's open. The red same-bar entry would precede the information used to trigger it; the green modeled action occurs only after the signal is known and must still be treated as an execution assumption. Illustrative teaching graphic · not live market data

Trace every input through time

Build a table of the rule’s fields: indicator values, rolling maximum or minimum, funding observation, market regime label, volume and any external event. For each, record its timestamp, finalization time and source. Check whether rolling windows accidentally include the current bar when they are meant to describe prior bars. Confirm that revised or corrected datasets did not replace what would have been known historically.

Treat publication time and event time as different fields. A funding rate can have an interval label but be posted or settled at a later point; an economic or exchange notice can be revised; a candle close has a declared interval boundary. Record both the event timestamp and when the value became available to the rule. For pivots, swing highs and lows, or labels that need later bars to confirm, store the confirmation delay explicitly. Do not backdate a confirmed label to the turning point unless the strategy could have acted then using only data already received.

Beware of labels created with hindsight. Marking a candle as “the local bottom” requires later observations unless the rule provides an explicit delay before confirmation. A news classification built from a final article may include wording published after the event. A current constituent list can omit assets that later disappeared. Even a filter that sounds descriptive can leak future information if its calculation spans the test boundary.

Inspect how the simulation processes each bar

Write the sequence for each observation: compute indicators, determine the signal, settle any relevant cash flows, evaluate open positions, submit or model the order, process protective levels, mark equity and save the ledger. The order matters. If a position enters after an opening settlement, it should not be charged as though it were open beforehand. If both a stop and target occur inside one candle, OHLC bars alone may not reveal which came first; the model needs a conservative or explicitly uncertain convention.

SuperQuant documents one specific sequence: intent uses the previous closed bar; existing positions receive an eligible funding settlement at the new bar’s open; eligible exits and entries are then evaluated; intrabar protective exits follow defined uncertainty handling. This limits look-ahead within that engine but remains a simplified hourly model. Bundled histories are synthetic. Review the current implementation and methodology when the product changes.

A small manual audit

Take one recorded trade and reconstruct it without using the summary chart. Identify the signal bar and the exact data known at its close. Recompute the indicator from the prior records. Find the modeled entry timestamp and verify it is later. Then trace each exit, fee and settlement to the event that was knowable then. Compare your hand calculation with the ledger. Investigate any discrepancy before interpreting performance.

After this timing review, evaluate parameter selection separately in the overfitting guide. The backtest tutorial and audit checklist help preserve the assumptions. A timing audit cannot prove a profitable or executable strategy; it can show that the test did not knowingly use unavailable information. This is general research education, not investment advice.

workflow to audit information timing in a backtestFor every signal input, identify its event timestamp and first knowable time, confirm the strategy uses only available values, model an order after its decision, then compare historical and realtime behavior. Unconfirmed higher-timeframe data, backdated pivots and revised labels return to the audit instead of being treated as available facts.TRACE EACH VALUE FROM WHEN IT HAPPENS TO WHEN YOU CAN ACT01 · Timestampevent + intervalsource version02 · Confirmbar close · post timerevision · delay03 · Decideconfirmed inputs onlyno future labels04 · Model orderlater eligible pricecosts + fill limits05 · Reconcilehistory vs realtimepreserve differencesUnconfirmed value or unexplained historical / realtime mismatch?Pause the interpretation · trace the data path · rerun after the rule is fixedAudit aid · timing correctness does not establish execution quality or profitability
For every signal input, identify its event timestamp and first knowable time, confirm the strategy uses only available values, model an order after its decision, then compare historical and realtime behavior. Unconfirmed higher-timeframe data, backdated pivots and revised labels return to the audit instead of being treated as available facts. Illustrative teaching graphic · not live market data