Time Travel

The core mechanism that reconstructs the exact state of all features at a specific historical timestamp. When a training label is generated at time T, time travel ensures only feature values with timestamps ≤ T are joined to that label.

• Prevents data leakage from future information
• Uses event timestamps rather than processing time
• Handles late-arriving data with configurable grace periods
• Essential for time-sensitive use cases like fraud detection and churn prediction

Two distinct temporal query modes that serve different use cases:

• AS AT: Returns the single most recent feature value at or before the specified timestamp. Used for point-in-time training dataset generation.
• AS OF: Returns all feature values and their timestamps up to the specified point. Used for time-series analysis and debugging feature evolution.

Understanding this distinction is critical for constructing correct training queries and avoiding subtle temporal bugs.

Time travel enables the reproducible creation of historically accurate training datasets by aligning feature values with label timestamps. The process:

1. Identify the entity (e.g., user ID) and label timestamp for each training example
2. Query the offline store for all feature values as they existed at that exact moment
3. Join features to labels without introducing temporal leakage

This guarantees that the model learns from data that would have been available in a production setting at prediction time.

When a new feature is defined, time travel enables retroactive computation across historical time ranges. The backfilling process:

• Replays source data through the feature transformation logic for each historical time window
• Materializes computed values into the offline store with correct event timestamps
• Validates consistency against existing features to detect data drift
• Enables immediate use of new features in historical training without waiting for data accumulation

Time travel enforces several critical consistency properties:

• Immutability: Once written, historical feature values are never overwritten, ensuring reproducible training runs
• Idempotency: Querying the same timestamp and entity combination always returns identical results
• Atomicity: Feature views are materialized as complete snapshots, preventing partial updates from corrupting training data
• Lineage tracking: Every feature value carries metadata linking it to its source data and transformation version

The foundational guarantee that enables time travel. It ensures that when constructing a training dataset, every feature value is joined exactly as it existed at the historical timestamp of the label, never using future data. This is the primary defense against data leakage, where a model inadvertently learns from information that wouldn't have been available in a real production scenario. Without point-in-time joins, a model's offline evaluation metrics become dangerously inflated and fail to predict real-world performance.

The analytical database (e.g., Snowflake, BigQuery, S3/Parquet) that persists historical feature values over long time horizons. Time travel queries are executed directly against this store. It must support time-travel SQL or APIs that allow filtering by event_timestamp to reconstruct the state of the world at any prior moment. The offline store is the single source of truth for generating massive, point-in-time correct training datasets for batch model retraining.

A logical abstraction that defines how raw data is transformed into a feature and how it should be retrieved for a specific model. A Feature View captures the transformation logic, the data source, and the entity it belongs to. When you execute a time travel query, you are typically requesting a Feature View at a specific point in time. This abstraction allows the feature store to consistently apply the same logic for both historical training data generation and real-time online serving.

The batch process of computing feature values for a historical time range. When a new feature is defined, it has no history. Backfilling runs the feature's transformation logic against the offline store's historical data to populate values retroactively. This is essential for enabling time travel for new features, allowing data scientists to include them in training datasets that span back months or years to validate their predictive power before promoting them to production.

The metadata map that tracks a feature's complete lifecycle from source to consumption. For time travel, lineage is critical for auditing. It answers: Which raw table and column did this value come from? What transformation was applied? At what timestamp was it materialized? This traceability allows engineers to debug why a specific value appeared in a historical training set and ensures full reproducibility and compliance for model audits.