Point-in-Time Correctness

The fundamental mechanism ensuring a feature's timestamp is strictly less than or equal to the label's timestamp. This prevents 'peeking' into the future.

• AS-OF Joins: The primary SQL pattern, joining feature tables to labels using feature_timestamp <= label_timestamp.
• Time Travel: Leverages table formats like Apache Iceberg or Delta Lake to query feature snapshots as they existed historically.
• Failure Mode: A naive left join without temporal logic will use the current value of a feature, leaking future information into the past.

Point-in-Time Correctness directly closes the gap between training and inference environments, ensuring logical consistency.

• Training Context: Features are computed using historical data available before the prediction moment.
• Serving Context: Features are computed using real-time data available at the prediction moment.
• The Contract: A Feature Store enforces this by using identical transformation logic for both historical backfills and online serving, guaranteeing the model sees the same data distribution.

Correctness requires precise alignment of the label's event time with the observation period of the features.

• Label Timestamp: Must represent the exact moment the outcome occurred, not when it was recorded in a database.
• Attribution Window: Defines how far back features can look. A label for 'churn on Day 30' should only use features from Day 0-29.
• Staleness Risk: If a fraud label is backdated by 7 days due to manual review, features must be recalculated for that earlier point, or the sample must be discarded.

Point-in-Time Correctness relies on Type 2 SCDs to preserve the historical state of mutable entities like customer tiers or addresses.

• Type 2 SCD: Tracks history by creating a new row with effective start/end dates for every change.
• Point-in-Time Query: WHERE feature.effective_date <= label.timestamp AND (feature.expiration_date > label.timestamp OR feature.expiration_date IS NULL).
• Anti-Pattern: Using a Type 1 SCD (overwriting old values) destroys historical accuracy, making it impossible to know a user's status at the time of the label.

The ability to reconstruct the exact feature set from any historical point is the ultimate test of correctness.

• Idempotent Pipelines: Backfill logic must be deterministic. Running it twice on the same historical window must yield identical feature vectors.
• Event Sourcing: Storing raw events in an append-only log allows complete reconstruction of state at any point in time.
• Data Versioning: Tools like DVC or lakehouse time-travel capabilities snapshot the input data, ensuring that a model trained on dataset-v1.2 can always be audited against the exact features used.

Statistical tests can identify temporal leakage when explicit join logic fails.

• Anomalous Feature Importance: If a feature like 'days since last login' has impossibly high predictive power, it may be leaking the label.
• Distributional Shift Check: Compare the distribution of features joined with correct AS-OF logic versus a naive join. A significant divergence indicates leakage.
• Holdout by Time: Always split train/test data chronologically. A model that performs perfectly on a random split but fails on a time-based split is a victim of temporal leakage.

The critical failure that point-in-time correctness prevents. Data leakage occurs when information from the future is inadvertently used to train a model, creating unrealistically optimistic performance metrics. Common causes include:

• Using aggregate statistics computed over the entire dataset before splitting
• Joining features based on a timestamp that post-dates the label
• Normalizing data using future mean and standard deviation

Leakage is often silent and catastrophic, discovered only after the model fails in production.

A centralized platform that enforces point-in-time correctness by design. Feature stores decouple feature engineering from model consumption and provide:

• Time-travel queries: Retrieve feature values as they existed at any historical timestamp
• Point-in-time joins: Automatically align features with labels without temporal leakage
• Consistent serving: Ensure the exact same transformation logic runs during training and inference

Popular implementations include Tecton, Feast, and Hopsworks.

A related failure mode where the feature distribution or transformation logic differs between training and inference. While point-in-time correctness addresses temporal skew, training-serving skew encompasses:

• Feature computation drift: Different code paths for offline vs. online feature generation
• Data staleness: Features updated at different frequencies in production than in training
• Missing values: Features available during training but unavailable at prediction time

Both skew types degrade model performance silently and require rigorous monitoring to detect.

A data lake capability that enables querying table snapshots as they existed at a specific timestamp or transaction ID. This is the storage-level primitive that makes point-in-time correctness possible:

• Delta Lake provides VERSION AS OF and TIMESTAMP AS OF syntax
• Apache Iceberg supports time travel through snapshot IDs
• Apache Hudi offers incremental queries based on commit times

Without time travel, reconstructing historical feature values requires complex and error-prone manual snapshotting.

A data warehousing pattern for managing attribute changes over time. Type 2 SCDs are essential for point-in-time correctness because they preserve full history:

• Each change creates a new row with effective date ranges
• Queries can reconstruct the exact state of a dimension at any historical moment
• Prevents overwriting past values that were valid at the time of the label

Without SCD Type 2, joining a customer's current segment to a historical transaction introduces temporal leakage.

An architectural pattern where state is derived from an append-only sequence of immutable events. This naturally supports point-in-time correctness because:

• The event log is a complete, ordered history of all changes
• Any past state can be reconstructed by replaying events up to a specific timestamp
• No data is ever overwritten, eliminating the risk of losing historical context

Event sourcing is particularly powerful for domains like finance and compliance where auditability is paramount.