Point-in-Time Feature Computation Engines

Knowing that a training feature must only use information available at the time is one thing; building a system that automatically enforces this across thousands of features, hundreds of data sources, and years of history without a human manually checking each one is a genuinely hard engineering problem. A point-in-time feature computation engine is the piece of infrastructure that does this enforcement mechanically — given a feature definition and a target date, it guarantees the computation only touches data that was actually knowable as of that date, rather than relying on every researcher to individually reason through the timing of every field they touch.

An analogy: a librarian who won't hand you tomorrow's newspaper

A librarian building an archive that lets researchers "look up what was known as of any past date" has to be strict about one thing: no matter how the archive is organized or searched, a request for "the news as of March 3rd" must never accidentally return an article published March 4th, even if it's about an event that technically happened on March 3rd but wasn't reported until the next day. A point-in-time feature engine plays exactly this librarian role for a feature store — no matter which feature or which historical date is requested, the system enforces that only data with a publication timestamp on or before that date is used, regardless of when the underlying event actually occurred.

The key mechanism: two timestamps per record

The engine's core trick is tracking two separate timestamps for every piece of underlying data: the event time (when the thing actually happened — an earnings result, a trade) and the knowledge time (when that information was actually published or became available to a downstream consumer, which is often later, sometimes by days, due to reporting lags or restatements). A point-in-time query for date $T$ filters strictly on knowledge time $\le T$, regardless of event time — so a feature engine effectively performs an "as-of join": for each row it needs to compute, it retrieves the most recent version of each underlying field whose knowledge timestamp doesn't exceed the target date, even if a newer, more accurate version of that field was published later.

Worked example: a quarterly-earnings feature done right and wrong

A "trailing 12-month earnings" feature is being computed for every stock on every day of a five-year backtest. A naive implementation joins each day to whichever earnings figure is "current" in today's database, which reflects any subsequent restatements since most databases overwrite old values rather than keeping history. A backtest date of March 15, 2022 might then silently use an earnings figure actually restated in 2023 — information nobody had in March 2022. The point-in-time engine instead stores every version with its own knowledge timestamp and, for the March 2022 query, returns only the version whose knowledge timestamp is on or before that date — the original, as-reported figure. Comparing the two approaches on the same signal shows the naive version's backtested Sharpe ratio is meaningfully inflated, purely from the restatement leakage.

What this means in practice

Building this properly means every raw data table entering the feature pipeline needs an explicit, reliable knowledge timestamp captured at ingestion, not reconstructed after the fact — retrofitting point-in-time correctness onto a database that only ever stored "current" values, with history silently overwritten, is often impossible without external vendor archives. Firms that get this right treat it as core data infrastructure investment; firms that skip it tend to discover the cost later, as a string of backtests that quietly overstate performance for reasons that take real effort to trace back to a timing bug.