Point-in-time-correct features
Point-in-time correctness preserves the knowledge boundary of the original decision.
Fraud labels arrive late and online features disagree with training data.
This chapter moves from anchor each example to select deterministically. 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.
Order eligible records by effective time, availability time, and revision, then take exactly one.
Verify the behavior illustrated in as_of_balance.sql, then measure decision utility, slice reliability, and system latency.
Joining only on customer ID attaches the present balance to every historical row. An unsafe release must degrade to a named baseline or the last known-good version.
Build the idea one layer at a time.
Historical features must answer a deceptively strict question: what value would the live system actually have returned at that past decision instant?
An as-of join chooses the latest state effective by the decision, but point-in-time correctness also requires that the state was available then. A late-arriving correction may describe yesterday accurately while remaining impossible for yesterday’s model to know.
Store effective time and availability time separately, and define deterministic tie-breaking for revisions. Otherwise a replay can select a different row even when the source events are unchanged.
- event time
- availability time
- as-of joins
- transform state
Follow the reasoning before touching the code.
- 01
Anchor each example
Give every prediction row an entity key and immutable decision_time that all feature lookups must respect.
- 02
Apply the dual cutoff
Require both effective_at and available_at to be no later than decision_time.
- 03
Select deterministically
Order eligible records by effective time, availability time, and revision, then take exactly one.
SELECT
p.transaction_id,
p.decision_time,
state.balance_usd
FROM prediction_events AS p
LEFT JOIN LATERAL (
SELECT a.balance_usd
FROM account_state_events AS a
WHERE a.account_id = p.account_id
AND a.effective_at <= p.decision_time
AND a.available_at <= p.decision_time
ORDER BY a.effective_at DESC, a.available_at DESC, a.revision DESC
LIMIT 1
) AS state ON TRUE;Recover the account balance knowable at each decision.
What to notice
- A corrected record with an old effective_at but late available_at is excluded from the historical lookup.
- The full ordering makes two events at the same effective time resolve identically on every replay.
YOUR TURN Pause and predict before revealing the answer.
At 10:00, two records are effective: balance 40 available at 09:58 and balance 60 available at 10:03. Which value belongs in training?
Need a hint?
Reconstruct the live lookup, not the most accurate later account history.
Check your reasoning
Use 40. The 60 balance was not available until three minutes after the decision.
Lessons 1 in this course.
Connect the chapter to the course’s quantitative spine.
Point-in-time correctness preserves the knowledge boundary of the original decision. The feature availability invariant 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.
Feature availability invariant
| Symbol | Meaning / shape / unit |
|---|---|
t_available | time the value became knowable |
t_decision | prediction cutoff |
f_i | feature i |
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: t_available, t_decision, f_i.
- 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_c03(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 preserves the knowledge boundary of the original decision. The path below shows where that reasoning needs an artifact, a test, an owner, or a fallback.
- 01
Turn “Anchor each example” into a written invariant and a failing test.
- 02
Promote as_of_balance.sql from illustration to a versioned implementation with representative fixtures.
- 03
Use “Select deterministically” as the release checkpoint: Order eligible records by effective time, availability time, and revision, then take exactly one.
- 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
Joining only on customer ID attaches the present balance to every historical row. 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.
Point-in-time feature system
Design a versioned training set and online lookup from transaction, account, and outcome events.
- Contracts and lineage
- Temporal join specification
- Late-event/backfill policy
- Offline-online parity report
Read primary material with a purpose.
Return to the opening failure.
Version contracts, temporal joins, transform state, snapshots, backfills, and continuous offline/online parity checks.
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 data contracts, point-in-time features, backfills, quality gates, and lineage.