Feature Freshness
How recent the data behind a model's input features is at the moment of inference, and the training-serving consistency problem it creates.
A fraud model that scores a transaction using a "transactions in the last hour" feature computed this morning is not a fraud model. Freshness is a first-class requirement for any model whose features describe recent behaviour, and it is routinely specified after the model is built rather than before.
The architectural difficulty is training-serving skew. Training features are computed in batch, over complete historical data, with the whole timeline available. Serving features are computed in streaming, incrementally, with only the past available. If the two computations differ in any detail — a different window boundary, a different null handling, a different definition of the same event — the model sees different distributions in production than in training, and its accuracy degrades in a way that is very hard to diagnose because nothing is broken.
The feature store pattern exists to fix precisely this: define the feature once, compute it for both paths from that single definition, and support point-in-time correct retrieval for training so a training row only sees feature values as they were at the moment of the labelled event. Getting that last part wrong produces label leakage and a model that looks superb offline and fails on contact.