Point-in-Time Correct Feature Joins

Preventing silent data leakage in training pipelines by joining features strictly as they existed at event observation time.

🔴 advanced5 min readdatamust-know

Point-in-Time Correctness (Time-Travel Join) ensures that training feature vectors contain only data available at or before event timestamp t. Joining features using standard SQL INNER JOIN or latest feature values causes Data Leakage (e.g. using user total 30-day spend computed today to train a model predicting a purchase 2 weeks ago). Modern Feature Stores (Feast, Hopsworks, Tecton) provide automated point-in-time joins using ASOF JOINs to guarantee zero feature leakage.

What is Point-in-Time Feature Leakage?

Consider predicting whether a loan application at t = 2026-03-01 will default:

  [ INCORRECT JOIN: Current State ]
  Event (2026-03-01) ──JOIN ON user_id──► User Features (2026-08-01)  <-- LEAKAGE! Contains 5 months of future data!

  [ CORRECT POINT-IN-TIME JOIN ]
  Event (2026-03-01) ──ASOF JOIN ON user_id & timestamp <= t──► User Features (2026-03-01)  <-- ZERO LEAKAGE!

If the feature table contains user_total_defaults = 2 (updated in July), joining it to a March event feeds the model future knowledge, creating severe Data Leakage.

Mechanics of ASOF Joins in Feature Stores

For an observation dataset O (Entity, Timestamp t_obs) and feature table F (Entity, Timestamp t_feat):

SELECT
  o.user_id,
  o.event_timestamp,
  f.credit_score
FROM observation_events o
ASOF JOIN user_features f
  ON o.user_id = f.user_id
  AND f.feature_timestamp <= o.event_timestamp

Timeline:  t1 (Feature v1)  ──────► t2 (Event Occurs)  ──────► t3 (Feature v2 Updated)
                                          │
                                    ASOF JOIN Picks v1! (Ignores v2)

Feature Store Architecture for Point-in-Time Joins

               Raw Logs & Data Sources
                         │
                         ▼
        [ OFFLINE FEATURE STORE (S3 / Parquet) ]
        - Historical Time-Series Feature Logs
        - Supports Point-in-Time ASOF Joins for Training
                         │
                         ▼
        [ ONLINE FEATURE STORE (Redis / DynamoDB) ]
        - Low-latency (< 5ms) Latest Feature Values
        - Serves Real-Time Online Inference

Say this out loud

"Point-in-Time correctness ensures training features contain strictly data available at or before event observation time t. Joining historical events with static latest feature tables leaks future information, inflating offline metrics while destroying online production performance. We prevent feature leakage by using Feature Stores that execute ASOF joins matching timestamps (feature_time <= event_time)."

Follow-ups to expect

What is Training-Serving Skew? A disparity between model performance during training vs production serving, often caused by feature definition mismatches or point-in-time feature leakage in offline training pipelines.
How do you test for point-in-time leakage in a pipeline? Run a temporal split validation: train on data before date T, evaluate on data after date T. If offline metric performance drops sharply when shifting from random k-fold to temporal splitting, point-in-time leakage is present.

Check yourself

Question 1 of 3

What happens when an ML engineer joins historical user events with a features table using a standard SQL `JOIN` on `user_id` without filtering on event timestamp?

More in MLOps & Production

See all →

Data Drift vs Concept Drift4 min What to Monitor in Production5 min Debugging a Production Model Incident5 min