Point-in-Time Correctness

Leaking the future

Suppose you train a churn model with label_date = 2026-04-01 and a feature account_balance from a balance table. A naive SQL join takes the most recent balance — which might be after the label date. The model now 'sees the future' during training and looks artificially accurate. In production it has no future, so it underperforms.

Point-in-time joins restrict each feature lookup to values available at or before the label timestamp. Feature stores do this for you; if you roll your own, the logic is non-trivial — and a frequent source of subtle bugs.

Imagine reviewing detectives' notes after a case. If you let yourself read notes written after the crime to judge a suspect, you'll always look like a brilliant detective. The only honest test is to read only what was available at the time. Same for training data.