Late event time does not imply past availability

Prerequisites and scoped previews

Events, identity and data contracts

Define keys, event/ingestion/availability times, schema evolution, dedupe and permitted use.

Leakage, splits and evaluation contamination

Prevent future information, entity overlap, preprocessing leakage and test-set reuse.

Feature engineering and transformations

Create numeric/categorical/text features, defaults and fitted transformations without leaking validation data.

Scoped prerequisite preview. The complete chapter is planned; this preview does not count as authored coverage.

What, when, why and how

Event time and serving availability

what: Event time describes the source fact. Serving availability describes when a validated value became readable by the decision path; an activation interval records when that version was current.
when: Use these for historical training joins, serving replay, late data, corrections and incidents.
why: An earlier event may arrive after prediction. Offline ingestion time is not necessarily online visibility, and an event-time-only join can leak a later backfill into an old decision.
how: Record event, ingestion, validation and actual online activation times with exact feature/entity/version identity. For serving replay require event_time <= decision_time and an active half-open interval [available_at, superseded_at). Reject overlapping active rows rather than guessing.

Freshness window versus storage TTL

what: A maximum feature age defines whether a value is useful at a decision time. Storage TTL controls eviction/retention and need not equal that maximum age.
when: Use separate contracts when deciding stale/default behavior and sizing historical/online storage.
why: A key can exist but be semantically stale, or be evicted while a historically valid value remains in offline storage. Running the query today must not move an old prediction’s freshness window to today.
how: Compute age relative to the decision timestamp and declared event/coverage time. Specify inclusive boundaries, missing/stale defaults and status flags. For aggregates, declare the window end/coverage definition rather than pretending every raw event timestamp is the freshness clock.

Serving replay versus corrected history

what: Serving replay asks what a specified release could read then. Corrected history asks for a later reconstruction of past facts under an explicit correction policy.
when: Use named modes for model diagnosis, backtests and analytical rebuilding.
why: A correction useful for analytics may be invalid for reproducing a past score. A mutable latest row cannot explain either question faithfully without version history.
how: Publish separate snapshot identities and lineage. Pin definitions, transforms, visibility intervals and the known-at cutoff for replay; label corrected datasets distinctly. Current access/deletion controls still apply to both modes.

Replay a late value with an activation interval

Synthetic feature count for tenant T1/entity U1/version v1: F1 has event time 09:00, value 10, online availability 09:01 and superseded_at 10:10. F2 has event time 09:30, value 40 and online availability 10:10, with no later supersession. A prediction at 10:00 reads F1, not F2. At 10:15 it reads F2.

At exactly 10:10 the half-open F1 interval ends and F2 begins, so only F2 is active. At 10:45 F2 is 75 minutes old by event time; under a 60-minute maximum age it returns an explicit stale/default result. At 10:30 the age is exactly 60 minutes and is accepted by this fixture’s <= convention.

The interval ledger records successful activations. An older raw event that is rejected by the current-value projector is not retroactively marked online-visible. If the platform lacks trustworthy activation timestamps/intervals, disclose that exact serving-state replay is unavailable. Offline corrected history is a different export.

Specify the temporal join contract

Join tenant, entity key, feature definition version and current lifecycle generation before choosing a value. Restrict event time and serving-availability interval at each prediction time, then check freshness. The exact transform/default contract is part of the feature request.

An independent SQLite fixture executes these conditions and compares the selected source IDs with JavaScript. It includes a cross-tenant row, exact activation/expiry boundaries, no matching entity and a deliberately weaker event-time-only join. SQL timestamps are normalized UTC strings in the fixture, not arbitrary timezone text.

Condition	Why it exists	Failure if omitted
Tenant/entity/feature/version/generation	Identity and authorized lifecycle	Cross-tenant or old-definition data leaks.
event_time <= prediction_time	No future source facts	Future behavior becomes a past feature.
available_at <= T < superseded_at	Actual serving-state interval	Late backfill or obsolete current value is used.
age <= max_age	Semantic freshness at prediction time	An existing but stale row looks usable.
Current permission/tombstone	Past data is not a permission bypass	Historical replay resurrects revoked data.

Choose the reconstruction you can support

A cheap latest-only online store is sufficient for current serving but cannot by itself reconstruct past availability. Retain a permitted append-only activation ledger or input snapshots when replay is required. Storage, privacy and write amplification are real costs.

A feature-store library may support temporal joins, created timestamps and TTL under provider-specific constraints. Validate the installed version and selected provider against your actual availability contract; this exercise uses its own interval fixture and does not claim a library default establishes online replay.

The scalar fixture assumes one coherent authoritative serving timeline. If replicas or caches can return older values, record the actual decision source/commit versions or enforce a read fence; otherwise activation history reconstructs only the authoritative view, not every request’s observed input. Clock and propagation limits belong in the replay claim.

Diagnose an impressive but invalid score

A backfill adds F2 tomorrow with an earlier event time, and offline validation improves. Check whether historical availability was moved backward, old snapshots were rewritten or feature selection ignored activation intervals. Rebuild under an honest known-at contract and report the invalid former result.

A tombstone or consent revocation may make a historical record unavailable now. Deny or use an approved redacted workflow; do not bypass access because the prediction predates the request. Keep permitted audit lineage separate from raw personal values.

Diagrams and relationships

Late event time does not imply past availability

The decision at 10:00 uses F1; successful activation at 10:10 makes F2 available only afterward.

Scroll horizontally on smaller screens, or enlarge the diagram.

Engineer, Senior and Staff follow-ups

These are teaching lenses. Each answer changes the scope of reasoning; they are not official employer leveling criteria.

Engineer: Why does F2 not belong in the 10:00 input?

Its source event is earlier but the value became readable only at 10:10. Serving replay uses actual visibility as well as source time and exact identity.

Engineer: What happens at the 10:10 boundary?

F1 ends exclusively and F2 begins inclusively. The fixture selects F2 alone; two active rows would violate the interval contract rather than justify an arbitrary tie-break.

Senior: How do you diagnose offline/current-store disagreement?

Compare the same tenant/entity/version/generation, as-of time, activation history, defaults and transform. A current value query and a historical replay query intentionally ask different questions; align them before comparing scores.

Senior: Can created_at automatically stand for online availability?

Only if the producer/materializer contract makes that true and the provider actually constrains it. Otherwise keep separate timestamps or declare the replay limitation; deduplication by created time alone is insufficient.

Staff: Who owns historical truth after a correction?

Source owners own correction semantics, platform owners own activation/lineage and consumers declare replay versus corrected-history needs. Version exports and benchmarks, document access/retention limits and avoid silently changing prior conclusions.

Staff: How do you evolve replay without retaining all inputs forever?

Choose permitted retention and sampling/input snapshots sufficient for the stated debugging window, record reconstruction limits and deletion propagation, and negotiate cost/coverage with domain owners. Exact unlimited replay is not a free platform property.

Practice and self-review

Your practice draft

Select F1/F2 for 10:00, 10:10, 10:15, 10:30 and 10:45 under a 60-minute age contract. Explain how an edit, backfill or deletion changes the query.

Explain your assumptions, calculation, alternatives and one failure.

Saved locally on this device. The worked answer does not score your draft. Existing lesson notes and completion are separate.

Progressive hints

Hint 1

Use successful activation intervals rather than event time alone.

Hint 2

Check the inclusive age boundary at each historical decision.

Hint 3

Current permission and version identity apply before returning any value.

Reveal worked answer guidance

10:00 selects F1; 10:10/10:15/10:30 select F2, with age exactly 60 minutes accepted at 10:30. At 10:45 return stale/default with source provenance. Backfills do not rewrite old activation times; definitions and access/deletion require explicit version/generation checks.

Evidence to check in your answer

Correct bitemporal and age conditions.
Replay/corrected history separated.
No overlap guessing or cross-tenant result.
Permission and retention limits explicit.

For each item, record Missing, Prompted, Independent or Adaptive evidence. Adaptive means you can revise the reasoning under a changed constraint. Reading completion and readiness are separate.

Sources and verification scope

Original synthetic examples and reference calculations. Sources support narrowly scoped background; they do not establish production performance or independent chapter review.

Feast point-in-time joins ↗ · Historical feature retrieval reference; actual availability/revision contracts still need explicit modeling.

Feast feature retrieval ↗ · Offline/online retrieval and contract vocabulary only. Original activation-interval fixture is platform-neutral; no Feast integration or provider/default guarantee.

Primary background links checked during authoring on 2026-10-19. Arithmetic, temporal eligibility, maturity and split reference functions are checked by the bounded local fixture suite. SQL is explanatory, not a migrated production query. No GPU, external dataset, model API or training job is required.

Point-in-time joins and feature availability