Feature Store Versioning¶
Governance registry — instantiates Task-Legible Feature Construction
Assigns immutable versions to feature definitions and records their lineage, so a model can be rebuilt on exactly the feature it was trained on.
A feature definition that silently changes underneath a deployed model is a landmine. Feature Store Versioning is the governance layer that stops this by treating each feature definition as a versioned, immutable artifact: when the computation of customer_lifetime_value changes, it becomes v3, and v2 keeps meaning exactly what it always meant. Its defining property is reproducibility through immutability — every version records the transformation code, the inputs it draws from, its owner, and its refresh cadence, so any model can name the precise feature versions it consumed and be rebuilt identically months later. It is not about whether a feature is good or drifting; it is about making sure that "the feature" is a stable, addressable thing at all, rather than a moving target that quietly desyncs training from serving.
Example¶
A ride-hailing platform serves an ETA model from a shared feature store used by a dozen teams. One feature, zone_demand_ratio, is redefined by its owning team to use a 15-minute window instead of 10. Under versioning discipline, that is not an edit — it is zone_demand_ratio@v4, published alongside the still-live @v3. The registry entry for v4 records the new transformation code, the two upstream tables it reads, the owner, an hourly refresh cadence, and a semantics note: "share of open ride requests in the zone over the trailing 15 minutes."
The ETA model in production pins @v3; the redefinition cannot silently reach it. When a new model wants the fresher window, it explicitly retrains on @v4 and records that dependency. Six weeks later, when an incident review needs to reproduce a bad prediction, the team pulls the exact version set the model named and recomputes the feature byte-for-byte. The versioning is what prevents training/serving skew — the model trains on one definition and scores on a subtly different one — which is otherwise nearly impossible to detect after the fact.[n1]
How it works¶
The mechanism is a discipline of registration and immutability:
- Register every definition. Each feature enters a central registry with its computation, inputs, owner, refresh cadence, and documented meaning — no anonymous features.
- Version on change, never overwrite. Any change to the computation mints a new version; old versions remain resolvable so past models stay reproducible.
- Pin dependencies. A consuming model records the exact feature versions it used, making its input set a reproducible manifest.
- Trace lineage. Each version links back to its raw sources and forward to the models that consume it, so the impact of a change is knowable before it is made.
The distinguishing act is immutable addressability: the point is not to observe a feature but to guarantee that a named version resolves to one fixed computation forever.
Tuning parameters¶
- Versioning granularity — bump on any change vs. only on semantic changes. Fine-grained guarantees exact reproducibility but multiplies versions to manage.
- Retention horizon — how long old versions and their materialized values are kept. Longer supports deep audits and reproducibility; storage grows without bound.
- Pinning strictness — models pin exact versions vs. float to "latest compatible." Strict pinning kills silent skew but forces deliberate upgrades.
- Lineage depth — trace to immediate inputs vs. all the way to raw sources. Deeper lineage powers impact analysis at higher capture cost.
When it helps, and when it misleads¶
Its strength is that it makes features reusable and auditable: teams share definitions without redefining them, incidents are reproducible, and the blast radius of a definition change is visible before the change ships. It is the direct remedy for "feature definitions differ across teams, making results irreproducible."
Its failure mode is version sprawl that ossifies rather than clarifies — hundreds of near-duplicate versions nobody dares retire, so the store becomes a museum and consumers pin ancient definitions out of fear. A classic misuse is treating versioning as a substitute for validation: a feature is faithfully versioned and reproducible while being wrong, and the tidy lineage lends it unearned credibility. Versioning guarantees you can reproduce a computation; it says nothing about whether that computation is any good. The guarding discipline is to pair the registry with retirement and validation — reproducibility is a floor, not a verdict — and to prune dead versions so the lineage stays legible.
How it implements the components¶
feature_store_registry— it is the registry: the central, versioned catalog of every feature definition and its metadata.feature_lineage_trace— each version records its inputs, code, owner, and consumers, giving the raw-to-model provenance chain.feature_semantics_record— every version carries its documented meaning and allowed use, frozen with the definition so semantics can't silently drift.
This registry does NOT implement drift_monitoring_signal — watching whether a feature's importance or distribution shifts over time is Feature Importance & Stability Dashboard, its nearest twin; the difference is that versioning freezes and traces definitions for reproducibility, while the dashboard observes deployed behavior. It also does not run the feature_validation_frame value test — that is Feature Ablation Comparison.
Related¶
- Instantiates: Task-Legible Feature Construction — supplies the registry, lineage, and reproducibility backbone.
- Sibling mechanisms: Feature Importance & Stability Dashboard · Feature Ablation Comparison · Leakage Scan · Categorical Encoding Scheme · Normalization & Scaling Pipeline · Interaction Term Construction · Lag & Window Feature Extraction · Domain-Derived Feature Template
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Feature Store Versioning operates as a durable record, ledger, register, or trace whose value depends on preserving actual state or history because it assigns immutable versions to feature definitions and records their lineage, so a model can be rebuilt on exactly the feature it was trained on.
Independent corroboration: The frozen evidence defines Feature Store Versioning as 'Assigns immutable versions to feature definitions and records their lineage, so a model can be rebuilt on exactly the feature it was trained on', so its operative form is Record, Log & Register.
Nearest alternative: Representation, Specification & Plan — The registry's value depends on immutable version and lineage history for actual feature definitions, beyond merely specifying them.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Data Science & Analytics
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Specialized
Rationale: Feature stores and their lineage controls arose in production machine-learning data infrastructure.
Related originating lineages:
- Computer Science & Software Engineering — Software configuration management and immutable versioning materially shape the registry mechanism.
Review outcome: Independent reviewer agreement; high confidence.
Notes¶
[n1] Training/serving skew is the mismatch that arises when the features a model is trained on are computed differently from the features it is served at inference time — a leading cause of silent production degradation in ML systems, and one that consistent, versioned feature definitions are designed to prevent. ↩