A January observation appears in a February release and is revised in March. Which value belongs in a decision made in February? Joining on January’s date cannot answer that question. The value and the time it became usable are one research input.
This research note proposes a leakage check. It does not report a new dataset audit or claim that any particular pipeline has passed one.
Keep the clocks separate
The observation clock identifies the period described. The release clock identifies public dissemination. The ingestion clock records when the system received the information. A revision introduces another version with its own availability history. A defensible feature requires the version usable at the decision time, not simply the latest value attached to an old date.
The Federal Reserve Bank of St. Louis documents this distinction through real-time periods. Ordinary FRED requests generally default to information available today; ALFRED-style real-time parameters retrieve information known during a past period.[6] A historical observation date is therefore not evidence that today’s downloaded value was known then.
Define the decision clock and processing delay explicitly. If the model depends on a vendor transformation, public release alone may not establish when that transformed input reached the model. Date-only vintage metadata may support a daily research design while remaining insufficient to warrant an intraday trade at the instant of release.
Conceptual example
Build a fixture with an initial release labelled A and a later revision labelled B for the same observation period. Put one decision after A becomes usable but before B does, and another after B. The first decision must receive A; the second may receive B. These are symbolic test records, not invented economic measurements.
Now give B a conspicuous marker and run the full feature-construction path. If that marker reaches the earlier decision, the pipeline has leaked future information even if its rows are perfectly date-sorted. Sorting a table is not the same as enforcing availability.
Cheap check
Run the fixture through ingestion, version selection and the feature join, not just a hand-written imitation of the final join. Include an entity with no eligible release and a revision arriving exactly at a decision boundary. Declare whether equality is admissible after accounting for processing time.
Pass: A reaches only the eligible earlier decision; B never appears before its usable time; an unmatched release remains explicitly unavailable. Every emitted feature retains its source version and availability timestamp.
Fail: future versions appear early, missing values become valid zeros, or the join discards provenance needed to establish eligibility. Stop inference on affected features until the clock defect is repaired.
A backward merge_asof can select the latest key no later than the decision key; pandas also provides exact-match and tolerance controls.[7] Use availability as that key and group by the appropriate identity. The function cannot certify that a timestamp supplied to it is truthful.
Limitations
Passing this fixture rules out the planted failure, not all leakage. Revised universe membership, fitted normalisers and model-training data need their own availability checks. Delaying everything by one row is not a general repair: irregular releases and mixed clocks can survive that shortcut. Conversely, an overly strict delay can discard information that really was usable; examine false exclusions as well as false admissions.
Follow drawdown’s valuation clock with execution-regime costs. See research infrastructure for the surrounding engineering questions.
Sources
[6] https://fred.stlouisfed.org/docs/api/fred/realtime_period.html — Federal Reserve Bank of St. Louis — FRED API Real-Time Periods [7] https://pandas.pydata.org/docs/reference/api/pandas.merge_asof.html — pandas — merge_asof reference