Point-in-Time Correct Feature Joins

For a training example tied to an event at time T, a point-in-time join selects the latest eligible feature observation for the same entity with an event timestamp at or before T, subject to a configured lookback window. This reconstructs event-time history instead of joining every example to the latest snapshot available when the training job runs. A feature table therefore needs stable entity keys, meaningful event timestamps, and enough history to answer the query. Event time and availability time are not always the same. A source event may happen before T but arrive late, or a value may be corrected or backfilled after T. If training uses that later-created value, it may not match what an online system could have served then. Feast documents an optional filter_by_created_timestamp setting for supported stores to constrain the created timestamp as well as event time; its docs note that NULL created timestamps are excluded and not all stores support the flag. This is an additional safeguard, not a universal property of every as-of join. A point-in-time join also cannot fix leakage already embedded in a feature, such as a count computed using future events, a label-derived field, or the wrong prediction cutoff. Engineers must choose the timestamp that matches the real decision, inspect source and transformation logic, and test representative rows against known historical examples. Compare offline training retrieval with the feature values that would have been available online. Document time zones, late-event policy, TTL, and backfill behavior. A join with correct mechanics can still be wrong if those inputs encode the wrong timeline.