11.07 · Concept
Feature Reuse, Discovery, and Governance
Create feature metadata that enables discovery, ownership, reuse, quality tracking, and safe deprecation.
Reusable features need product-grade metadata: definition, computation, entities, time windows, sources, owners, quality signals, access rules, lifecycle status, and known consumers. With that in place, engineers can find existing features, judge whether they are trustworthy, avoid duplicate work, and retire unsafe or obsolete features without breaking downstream models.
What this lesson answers
- what metadata should a feature store capture
- how to make machine learning features reusable
- how to deprecate feature store features safely
Notes
Feature reuse depends on treating features as shared data products rather than one-off columns hidden inside a training pipeline. A feature should have metadata that tells other engineers what it represents, how it is computed, which entities and time windows it applies to, what data sources it depends on, and where it is available for training and serving. Good metadata makes discovery possible: instead of rebuilding “customer_30_day_spend” for every model, engineers can search the feature store, inspect its definition, understand its freshness and historical availability, and decide whether…
Common questions
- What metadata makes a feature discoverable?
- A discoverable feature has a clear name, business meaning, computation logic, entity grain, time window, source datasets, freshness expectations, and locations for training and serving. Engineers should be able to search for it, understand whether it matches their modelling use case, and see how it differs from similar features.
- Who should own a shared feature?
- A shared feature should have an explicit owner or owning team responsible for correctness, documentation, access decisions, incident response, and lifecycle changes. Ownership prevents feature stores becoming anonymous column dumps where nobody can explain a value, approve sensitive use, fix bad data, or coordinate migration when the feature changes.
- How should feature deprecation work?
- Feature deprecation should be handled like an API change. Mark the feature status, publish the replacement, identify consumers, communicate the migration path, monitor remaining usage, and remove it only after dependencies are cleared. This keeps the store clean without surprising teams or silently degrading production models.