Feature pipelines need point-in-time contracts before reusable stores

Feature pipelines need point-in-time contracts before they need a reusable feature store. Reuse makes a feature easier to consume; it does not make the feature historically correct. Unless the platform defines what was known, when it became available, and how later corrections behave, reuse simply distributes leakage and inconsistency more efficiently.

The first contract is temporal grain. A feature such as “orders in the previous seven days” needs an entity key, event-time definition, window boundaries, timezone, and inclusion rule. It also needs an availability time: the moment the value could actually have been observed by the model. A transaction may occur at noon, arrive at the lakehouse at 12:08, and be corrected tomorrow. Training on the corrected value as though it was visible at noon leaks future knowledge into the past.

This is why point-in-time correctness is not a join option hidden inside a training SDK. It is part of the feature’s public meaning. The contract should state which timestamp governs eligibility, how late events are handled, whether backfills rewrite history, and which source snapshot produced each value. Bi-temporal modeling is table stakes because event truth and platform knowledge are different timelines. A feature pipeline that collapses them cannot reconstruct the evidence available for an earlier prediction.

Streaming aggregation makes the obligation visible. Continuous processing buys freshness at the cost of more state and more complex late-data handling. Interval aggregation accepts bounded staleness. Compacted or precomputed modes trade some freshness for cheaper reads and simpler operations. None is universally correct. The contract must name the freshness target, allowed lateness, update cadence, and correction policy so a consumer can decide whether the feature fits a fraud decision, a daily forecast, or an offline experiment.

The same definition must survive the offline-online boundary. Training may read a historical lakehouse table while serving reads a low-latency projection. If the two paths implement different windows, null treatment, or normalization, the model is trained on one feature and operated on another. I want one versioned logical definition, separate materializations, and parity tests over shared fixtures. The store is then a delivery mechanism for the contract, not the source of truth for meaning.

Versioning matters when meaning changes without a type change. Extending a lookback from seven to thirty days, changing an entity-resolution rule, or excluding refunded orders can leave the schema untouched while altering the learned signal. Data contracts are the API layer; feature contracts need the same breaking-change classification, consumer impact analysis, and migration window. Model versions should record the exact feature-definition versions and snapshots used to train them.

Observability follows from those commitments. Monitor freshness, late-arrival rates, null and distribution shifts, offline-online parity, and point-in-time join failures against declared thresholds. Data quality is a distribution contract, but feature quality also includes temporal availability. A statistically familiar value delivered after the decision is still wrong.

There is one precise concession: a feature computed inside a single bounded experiment, with no reuse and no production decision, can keep its temporal assumptions in the experiment specification rather than a platform-wide contract registry. The moment another model consumes it, the source refreshes, or an online path appears, those assumptions become shared infrastructure and need an enforceable interface.

A feature store earns its place after this work. It can provide discovery, historical retrieval, online serving, lineage, and access control. But those capabilities are valuable only when they carry an explicit point-in-time promise. I would rather have a small catalog of features whose historical semantics can be replayed than a large marketplace of convenient numbers that nobody can prove were available when a model acted.