Point-in-time data: avoiding look-ahead bias

Reviewed 2026-10-15

Point-in-time data preserves what was available at a past decision date. Learn to handle revisions, delayed records and historical joins with worked examples.

What does point-in-time mean?

Point-in-time data preserves the information available at a specified historical decision time. It separates when an event happened from when the information became available, and it retains revisions rather than silently replacing earlier values. This lets a backtest reconstruct an information set that could actually have been used.

A historical date column alone is not enough. A January observation corrected in March still describes January, but the correction was unavailable in February. ALFRED makes the distinction explicit through real-time periods: the FRED API normally returns what is known today, while a historical real-time period requests what was known at an earlier date.^[1]

Four times that should not be collapsed into one

A useful record distinguishes the following times where the source provides them. Field names vary across vendors, so check definitions and time zones rather than inferring meaning from a label:

• Observation time: when the measured activity occurred or the period the value describes.
• Publication time: when the source released that version of the information.
• Receipt time: when the delivery reached your own system.
• Revision time or version: which release, correction or replacement the row belongs to.

For a replay of your own production pipeline, a record cannot enter the decision before it was received and processed. For a study of public availability, publication time may be the appropriate boundary, with an explicit retrieval delay. State which experiment you are performing. Using the earliest conceivable availability in one dataset and actual receipt in another makes the comparison inconsistent.

A worked example of look-ahead bias

Consider a hypothetical January hiring index first released on 7 February at 100. A correction published on 10 March changes the January value to 112. A strategy making a decision on 15 February could use 100, assuming it had received the release. It could not use 112. On 5 February neither value was available, even though both rows describe January.

A latest-history download in April may show only 112 next to January. Joining it to returns by observation month would place future information into the earlier decision. Delaying the series by a few days does not repair this example, because the important revision arrived more than a month after the original release.

Keep both releases with their availability times. For each decision, select the latest eligible version, then compute the feature from that selected history. Do not first compute a revised growth rate across the final series and merely shift its result backwards or forwards.

Real sources where the distinction matters

FRED's real-time start and end parameters allow vintage-aware requests where the archive has the relevant history. The documentation distinguishes observation dates from the period during which information was known. This is a useful public example of why a current historical download and an as-of download can answer different questions.^[1]

Indeed Hiring Lab documents a November 2024 change to seasonal adjustment and notes that historical numbers were revised. A current job-posting index should therefore not be assumed identical to the index released before the change. A repository history can help find older files, but check that a chosen commit actually corresponds to a publicly available release rather than treating every commit as an authoritative release timestamp.^[2]

SEC EDGAR publishes submissions and XBRL facts as filings are disseminated. A financial fact's reporting period is different from its disclosure date. Preserve the filing identity and publication evidence, and do not use a later filing or amendment to populate an earlier decision merely because it reports the same financial period.^[3]

Build an as-of join in the right order

First define the decision timestamp, observation unit and logical record key. A key might combine issuer, metric and reporting period, or employer and job identifier. Next exclude every version whose availability is later than the decision. Within the remaining versions of each logical record, select the most recent eligible version. Only then calculate aggregates and model inputs.

Apply the same rule to supporting tables. Company ownership, ticker mappings, store lists and industry classifications can change. Joining historical observations to today's company map can introduce future information even when the observations themselves have correct timestamps. Preserve mapping versions or document where an as-of mapping cannot be reconstructed.

Handle deletions explicitly. A role removed in March may still belong in a February count. Removing it from the whole historical table because it is absent today creates a different error from keeping a later correction, but both distort the historical information set.

What to retain from each delivery

Retain the original file or response, a receipt timestamp, the source location, the query parameters and a content hash. Keep the data dictionary and parser version with the processed output. These records help explain why the same source generated different features after a collection or processing change.

Snapshots can establish a reliable archive from the day collection begins. They cannot prove that an older history downloaded for the first time today was available years ago. Ask the vendor whether earlier releases, backfill flags and change logs are available. If not, distinguish an exploratory retrospective study from a verified historical replay. Delivery formats and pipelines covers the operational choices.

Checks before trusting the backtest

Test a few deliberately awkward dates, including one before the first release and one between an original publication and its revision. Inspect the selected records manually. The corrected value should appear only after its availability boundary, and an unreleased observation should remain absent.

Then run sensitivity checks with a plausible extra delivery delay and compare vintage-aware results with a latest-history baseline. A large difference is a reason to investigate, not evidence that either result is correct by itself. Also check the contemporaneous company universe, training labels and feature transformations. Point-in-time inputs are necessary for a credible replay, but do not eliminate overfitting, transaction costs or changes in the underlying economy.

Include these checks in the vendor evaluation. When buying job market data, request both active and removed records and a definition of first-seen time. Price historical-version access separately if it is not included in the standard delivery.