Feature platforms and point-in-time correctness
Point-in-time correctness reconstructs what the system knew, not what the database knows now.
A late feature silently corrupts every downstream prediction.
This chapter moves from declare the entity and cutoff to test both materializations. We will make the idea concrete in a small code example before placing it back inside a production system with a declared latency, cost, and operator-capacity budget.
Create fixtures with late, duplicated, missing, and boundary-time events and assert offline/online agreement.
Verify the behavior illustrated in point_in_time.sql, then measure decision utility, slice reliability, and system latency.
A backfill uses corrected future knowledge and silently inflates offline AUC. An unsafe release must degrade to a named baseline or the last known-good version.
Build the idea one layer at a time.
A feature platform is valuable when one definition produces faithful historical values and low-latency online values. If the offline join sees information the online system did not yet know, the platform has automated leakage rather than prevented it.
For a prediction at time t, a feature event is eligible only if its event time and availability time are no later than t. The lookup then selects the latest eligible value for the same entity. Availability matters because an event that happened yesterday but arrived tomorrow was still unavailable to today’s prediction.
Offline and online stores need not be the same database. They must share entity keys, transformation semantics, time rules, defaults, types, and version identity. Parity tests should replay raw requests through the online path and compare them with the historical materialization at the identical cutoff.
- watermarks
- feature stores
- Airflow/Dagster
- MLflow
Follow the reasoning before touching the code.
- 01
Declare the entity and cutoff
Every training row needs an entity key and the exact historical prediction time it is intended to reconstruct.
- 02
Select only eligible history
Filter on both event_at and available_at, then choose the latest eligible event without using present-day state.
- 03
Test both materializations
Create fixtures with late, duplicated, missing, and boundary-time events and assert offline/online agreement.
SELECT p.prediction_id, p.customer_id, f.risk_score
FROM predictions p
LEFT JOIN LATERAL (
SELECT risk_score
FROM risk_feature_events f
WHERE f.customer_id = p.customer_id
AND f.event_at <= p.prediction_at
AND f.available_at <= p.prediction_at
ORDER BY f.event_at DESC, f.available_at DESC
LIMIT 1
) f ON TRUE;An as-of lookup excludes future and late-arriving knowledge
What to notice
- The lateral lookup is evaluated against each prediction’s own cutoff instead of attaching one present-day feature value to all rows.
- Ordering by event and availability time makes the selected revision deterministic when multiple eligible records exist.
YOUR TURN Pause and predict before revealing the answer.
A feature event happened at 09:00, arrived at 10:05, and the prediction was made at 10:00. Is it eligible?
Need a hint?
Both temporal conditions must be satisfied.
Check your reasoning
No. Its event time is early enough, but its availability time is five minutes after the prediction, so the online system could not have used it.
Lessons 1, 2 in this course.
Connect the chapter to the course’s quantitative spine.
Point-in-time correctness reconstructs what the system knew, not what the database knows now. The point-in-time feature lookup below is the shared course-level lens that helps quantify the surrounding system. Name each symbol, check its units or shape, and use only values that were available at the production cutoff.
Point-in-time feature lookup
| Symbol | Meaning / shape / unit |
|---|---|
j | entity |
t_p | historical prediction time |
e | eligible event |
Open derivation and numerical substitution
Start from the production quantity being optimized, substitute the observed values with their declared units, then isolate the model-controlled term. Preserve shape annotations at each step so broadcasting or aggregation cannot silently change the result.
- Write the named inputs: j, t_p, e.
- Substitute one small, hand-checkable batch before vectorizing.
- Calculate an independent reference value and compare within a declared tolerance.
# equation → code contract
inputs = validate_shapes_and_units(batch)
value = compute_c17(inputs)
assert is_finite(value)Change one assumption and make the tradeoff visible.
Use the worked chapter as your prediction, then change one input in the lab and explain why the output moves. The lab runs predefined TypeScript and never executes learner code, so the focus stays on the concept rather than setup.
Point-in-time freshness lab
Delay feature arrival and see which historical rows remain eligible.
Assumption: Five events have fixed prediction cutoffs separated by six hours.
Open nonvisual data table
| Item | Computed state | Interpretation |
|---|---|---|
| row 1 | cutoff +0h | not yet knowable |
| row 2 | cutoff +6h | eligible |
| row 3 | cutoff +12h | eligible |
| row 4 | cutoff +18h | eligible |
| row 5 | cutoff +24h | eligible |
Trace the complete operating path.
Carry the chapter’s central idea into the system: Point-in-time correctness reconstructs what the system knew, not what the database knows now. The path below shows where that reasoning needs an artifact, a test, an owner, or a fallback.
- 01
Turn “Declare the entity and cutoff” into a written invariant and a failing test.
- 02
Promote point_in_time.sql from illustration to a versioned implementation with representative fixtures.
- 03
Use “Test both materializations” as the release checkpoint: Create fixtures with late, duplicated, missing, and boundary-time events and assert offline/online agreement.
- 04
Serve or materialize behind explicit a declared latency, cost, and operator-capacity budget.
- 05
Join telemetry to mature outcomes and retain a rollback path.
Observability
Join service health, input quality, prediction distributions, slice behavior, and mature outcomes by exact version.
Cost
Measure storage, preprocessing, compute, queueing, and human review under a representative arrival pattern.
Failure modes
A backfill uses corrected future knowledge and silently inflates offline AUC. Add a detector, owner, mitigation, and stop condition for this class of failure.
Alternatives
Compare a rule, a simpler statistical baseline, and a different system boundary before adding model complexity.
Explain the contract, not just the vocabulary.
Local mini ML platform
Specify idempotent events, a point-in-time join, shared feature definition, quality gates, lineage, and model registration.
- Data contract
- Late-event semantics
- Feature parity design
- Lineage/registry record
Read primary material with a purpose.
Return to the opening failure.
Make temporal correctness, ownership, lineage, reproducibility, and escape hatches the platform defaults.
For this lesson, the release evidence is the worked code example, a hand-checked formal result, deterministic simulation output, a ≥80% checkpoint, the production rubric, and a named fallback. The course resolves when the system can produce a traced batch/stream platform with orchestration, registry, lineage, and ownership.