Point-in-time data and survivorship bias

Two defects, often confused

Survivorship bias can arise when historical tests use a current universe that excludes names that later disappeared. Retaining inactive instruments and their exit history helps investigate the effect. Its direction and size depend on the strategy and the missing records.

Look-ahead bias arises when a historical decision uses information that became available later. Restated earnings, revised index membership and corrected macro releases need their availability dates attached.

Historical universe records address membership changes. Availability timestamps address information timing. Review the coverage of each separately, because evidence for one does not establish completeness for the other.

What 'point-in-time' actually has to mean

A dataset is point-in-time when every row carries two distinct times, and queries can be filtered on the second one:

• Effective time is the period the value describes, such as an earnings quarter, trade date or reference month for a macro series.
• Availability time is when the value became publicly knowable, such as the filing, disclosure or publication date.

An as_of query selects the rows available by the requested date, using the values recorded at that time. Applying that rule requires retained availability timestamps and revision history.

Revisions, amendments and the shape of the truth

Different sources revise in different ways, and a dataset's revision model tells you which kind of history you are querying.

• Filing history with amendments. The original filing stays, and an amendment arrives later as its own row. Both are true at their own availability times. Institutional holdings disclosures and insider transactions behave this way.
• Rolling disclosure history. Disclosures arrive on a schedule with a reporting lag, and the lag is itself part of the data.
• In-place restatement. The value is overwritten. An as_of query can recover an earlier value only if its vintage and availability history were retained. Inspect the revision policy before using the dataset in a historical test.

If you are pinning a research result, the revision model is the thing to check first. A dataset that restates in place cannot reproduce last quarter's answer, no matter how carefully you version your code.

Delisted-name retention and coverage

The fix for survivorship bias is to keep inactive and delisted instruments in the reference directory, so a historical universe can be rebuilt from what existed at the time rather than from what exists now. TradePolaris retains them wherever the source supplies them.

Retaining delisted symbols helps address survivorship bias. Completeness still depends on the supplied history, the membership records and the handling of missing exit returns. Review the coverage for the dataset and the universe mode stored on the run.

The check that catches it

TradePolaris records universe-integrity evidence as part of the validation panel. Current-constituent fallbacks have explicit warnings, and the published methodology states which verdicts affect qualification. Read the statistical robustness gates alongside the run evidence.

Reproducing an answer a year later

Point-in-time support records what was available at a decision time. Version pinning records the dataset used by a particular run. Retain both when reproducing an analysis.

1. Pin the dataset version alongside the result and the query. A later version may contain revised values and produce a different result.
2. Record the as_of used, separately from the run date. The availability cutoff and the execution date describe different parts of the experiment.
3. Store the universe and its selection rule. Keep the instrument list used by the run, because applying the rule later can produce a different set.
4. Keep the coverage window returned by the query, including the knowledge-time bounds. An as_of before retained coverage falls outside the available evidence. Document that gap when interpreting the result.