11.01 · Concept
Feature Engineering Lifecycle
Describe the lifecycle of a feature from definition and computation to validation, serving, monitoring, and deprecation.
A production feature is a governed data product: defined against a modelling need, computed without leakage, validated for correctness and timing, served consistently for training and inference, monitored in operation, then retired when no longer useful. The lifecycle prevents duplicated logic, stale assumptions, and silent model failures.
What this lesson answers
- how should a machine learning feature be defined
- how to avoid training serving skew in features
- when should a feature be deprecated
Notes
A feature’s lifecycle starts with a clear definition tied to a product or modeling need. A working engineer should treat a feature as a data product: specify what it means, the entity it belongs to, the time window it uses, its expected freshness, and how it should behave for missing or late-arriving data. For example, “number of purchases in the last 30 days” is not complete until the event source, timezone, aggregation window, deduplication rules, and point-in-time behavior are defined.
Common questions
- What information belongs in a feature definition?
- A useful feature definition states the entity, source data, calculation logic, time window, freshness expectation, missing-data behaviour, late-data handling, and point-in-time semantics. Without those details, engineers can implement plausible but incompatible versions of the same idea, especially across training, backfills, batch scoring, and live inference.
- Why does point-in-time correctness matter for features?
- Point-in-time correctness ensures a model only uses data that would have existed at the moment of prediction. A feature can be syntactically valid and still leak future information through aggregation windows, backfills, delayed events, or joins. That makes offline evaluation look better than production behaviour.
- What should be monitored after a feature reaches production?
- Production monitoring should cover schema changes, nulls, ranges, freshness, distribution shifts, drift, serving latency, and which models or systems consume the feature. These signals help catch broken upstream pipelines, changed product behaviour, and features that remain served even though nothing important depends on them.
Short definition: what is Feature Engineering Lifecycle?