Engineering, production, governance, cost, communication · insight-0258
Give every feature a freshness SLA and enforce it at serving time
- Evidence type
- practitioner heuristic
- Difficulty
- medium
- Roles
- ML engineer
- Industries
- banking, e-commerce, telecom
Summary: situation, action, reason, boundary
Situation
A fraud model's 'transactions in the last hour' feature comes from a stream that sometimes lags by 40 minutes.
Action
Record for each feature its expected maximum staleness and how it was trained (with what lag), check the event timestamp of the served value against that limit, and emit a metric and fallback when it is exceeded.
Reason
A feature's meaning depends on its age; serving it older than in training is a form of skew.
Boundary
Streaming and near-real-time features, feature stores with time-to-live settings.
Symptom or risk
Stale values look valid, so the model scores with outdated behaviour and misses fast attacks, while dashboards show a healthy service.
Exceptions
Slowly changing attributes (customer tenure) tolerate long staleness.
Trade-offs
Tight SLAs increase infrastructure cost and fallback frequency.
Pitfalls
Training on perfectly fresh historical features while serving with real pipeline delays.
Lessons and concepts
Claims and their sources
Feast point-in-time joins look back from each entity timestamp only up to the feature view's TTL.