Point-in-time correct training joins

Event time identifies when an observation happened or the interval it describes. Availability or knowledge time identifies when the chosen serving path could use that particular version. An ingestion timestamp can approximate availability only when the pipeline contract makes that true; a record entering a warehouse at noon may not reach the online store until several minutes later. Corrections add another distinction: the effective event can remain yesterday while a revised value becomes available today. Retain the earlier version if historical serving reconstruction needs it.

For each training entity row, choose a decision timestamp with the same interpretation as the production decision. Filter candidate features by entity identity, valid event-time range, and the required availability cutoff before selecting the latest eligible version. Do not filter using the time a delayed label was finalized if the real prediction occurred earlier. A snapshot query against a warehouse today can provide a consistent database view while still including information unavailable at the historic prediction; transactional consistency alone is not an anti-leakage policy.

Within eligible candidates, select the newest event time and a documented revision order for equal event times. A later correction with the same event timestamp must not win an as-known join when its availability lies after the decision. Duplicate physical rows representing the same revision need deterministic deduplication. Missing created or availability timestamps require an explicit policy; treating unknown time as negative infinity silently upgrades uncertainty into historical knowledge. Preserve enough provenance that a reviewer can explain why one row was eligible and another was excluded.

Feast v0.66.0 exposes get_historical_features with filter_by_created_timestamp, defaulting to false. The referenced documentation explains that default joins constrain event timestamps, while created timestamps ordinarily help deduplicate equal-event-time rows. Enabling the supported filter adds the created-time cutoff and excludes null created timestamps; unsupported offline stores reject it. This implements as-known behavior only if that field actually represents the required availability and is populated correctly. It cannot recover overwritten historical versions, infer delayed online publication, or compensate for a transformation that used future inputs before producing its row.

Build fixtures containing a late event, a same-event-time correction, an event after the decision, an observation beyond the horizon, and two entities with similar keys. Verify selected values and rejected candidates explicitly. Keep corrected-truth evaluation separate from serving reconstruction so a desirable backfill is not mislabeled as historical online parity. A dataset release should record the retrieval policy, source snapshot, transformation revision, decision-time column, and availability assumptions. Without those details, rerunning the same SQL months later may answer a different temporal question.

The modular instrument illustrates that a later state is not an earlier observation. Reset, set both m=12 and a=1, predict residue two, then Step twice. Separately Reset, set both m=12 and a=1, predict residue five, then Step five times. Selecting the later value does not reconstruct the earlier position. This exact cyclic counter stores no historical rows, availability dimension, TTL, or join logic. It supports the limited distinction between the current state and the state associated with a specified earlier execution position.