What is lookahead bias? Using information that was not yet known
Learn how lookahead bias arises from information timing and the misuse of future evaluation labels.
Ask whether it was knowable at the decision time
Lookahead bias occurs when a historical decision uses information that could not yet have been known at that time. A table collected later may contain historical dates without every value having been available then. Revised figures inserted into the past can create the problem even without an explicit reference to future rows.
Ask not only what date information describes, but when it became available and which order used it. See data availability and lookahead for the basic timing distinctions.
Separate signal formation from execution
A signal formed from a closing price cannot be used in an order submitted before that close was known. A backtest that decides from the close and assumes guaranteed execution at the same close needs evidence that information receipt and order acceptance could occur in that order. A price appearing in a table does not prove that sequence.
The public GUI reference rule forms signals from closes no later than the previous observed session and executes at the next observed session's actual open. Recording signal dates, quantity decisions and execution dates separately helps trace information use. That structure alone does not guarantee historical availability for all data.
Do not feed future labels back into inputs
Factor evaluation asks whether characteristics at a given time relate to subsequent returns. Those future returns are evaluation labels, not information for a prediction made that day. Loading a label-containing table directly as strategy input can supply the answer in advance.
The public course separates features calculated from prior-day information from labels using later observed sessions. Rows lacking enough future data at the end remain missing. Check column meanings and calculation intervals rather than trusting filenames alone. Label intervals also matter when reading IC.
Consider a fictional after-close announcement
Suppose a fictional company releases earnings information after trading ends on a given day. This is a timing illustration, not an actual company event or a statement of current exchange hours. The announcement cannot be inserted into a signal formed before trading ended that day.
Record the period described, first publication time, researcher receipt time, signal calculation time and earliest possible order time. Even for next-day use, check whether receipt and processing completed in time. A date labelled “next day” is insufficient. If timing is unknown, retain that uncertainty rather than assuming availability.
Reproducible results still need timing checks
Producing the same results from the same files and rules establishes reproducibility. It does not establish that each input was visible at the relevant decision time. High returns and consistent accounting cannot remove an information-timing problem. Check timing first, then interpret performance under the verified conditions.
The public reference examples are research-only, with historical availability unverified. Continue to point-in-time data to distinguish frozen data from historical information versions. The results checklist begins with report inputs and assumptions before the curve.
Public sources and research limitations
The workflow and display sources are the public GUI research course and public evidence summary. Reviewed October 6, 2026. The images record a GUI run from public-candidate source; they do not establish installed-distribution acceptance.
Reference results are research-only, with historical information availability unverified. Do not infer future profits from teaching examples or reference results; check their assumptions and limitations. Read the disclaimer.
Continue this topic
Applies to: main source candidate (unpublished) · Public source docs/en_US/GUI_RESEARCH_COURSES.md
Reviewed · KabuForge