The Registry and Feature Definitions
In one line: the registry is where a feature stops being code somebody wrote and becomes an asset with an owner, a version and a meaning.
What a definition holds
| Field | Why it exists |
|---|---|
| Name and description | Discovery — someone has to find it before they can reuse it |
| Entity key | What it is keyed on: user, item, user-item pair, session |
| Transformation | The computation, expressed once |
| Source | Which tables or streams it reads |
| Freshness / schedule | Batch daily, streaming, or on-demand |
| Data type and valid range | What monitoring checks against |
| Owner | Who to ask, and who is paged |
| Version | So a model can request the definition it trained on |
| TTL | When a value stops being usable rather than merely old |
The last three are the ones distinguishing a registry from a shared code library, and they are why sharing the transformation is not the whole answer.
Entity keys are the decision people skip
The most consequential field, and the one that gets least thought.
A feature is keyed on an entity, and choosing the entity determines what the feature can express and how much it costs.
Pair features are where the cost explodes, and the ranking chapter showed why they are also the most valuable — they express the interaction only the ranker can see. The resolution is that pair features are stored sparsely, only for combinations that occurred, with a default for the rest. Which means the default value is itself a modelling decision, and "this user has never bought from this seller" needs to be distinguishable from "we have no row".
A composite entity is often the right answer and is rarely the first one tried. "This user's purchases in this category" is keyed on user-and-category, which is a far smaller space than user-and-item and captures most of the signal.
Discovery is the largest benefit
The technical framing undersells this. In an organisation with several ML teams, the same features are rebuilt constantly — days-since-signup, lifetime value, session count — each subtly different, each maintained separately, each a place skew can enter.
A registry that is searchable, with descriptions, owners and usage counts, turns that from an unavoidable cost into a solved problem. Someone building a new model looks first, finds a maintained feature, and uses it.
Two things make that actually happen, and both are unglamorous:
Usage counts. Seeing that a feature is used by eleven models is what makes someone trust it. It also tells the owner what they cannot break.
A quality signal. Freshness, null rate, last successful run. A registry listing features with no indication of health invites people to depend on something broken.
Where the transformation is expressed
A real design decision with a real trade.
Declarative, in the store's own language. The store owns the computation and can materialise it to both paths, optimise it, and reason about lineage. The cost is expressiveness — anything the language cannot say has to live elsewhere — and a learning curve for people who were fluent in SQL.
Registered pointers to external pipelines. The store records what exists and where, and someone else computes it. Flexible, and it gives up the guarantee: two pipelines can now diverge again, and the registry is documentation rather than enforcement.
Most real systems are a hybrid — simple aggregations declared in the store, complex ones computed externally and registered — and the honest framing is that the second category is where skew can still enter, so it should be a deliberate exception rather than a default.
On-demand features
The third pipeline type, and the one that only makes sense here.
Some features cannot be precomputed because they depend on the request: the query text, the current time relative to the user's timezone, the ratio of this item's price to what the user typically pays.
These are defined in the registry and computed at request time from values already in hand. Keeping them in the registry rather than in application code matters for one reason: training must apply the same transformation. An on-demand feature computed in the serving service and reimplemented in a training notebook is the original problem, reintroduced in the one place people forget to look.
Key takeaway
A definition is more than a transformation — the owner, version and TTL are what separate a registry from a shared library, and they are what let a model request the exact feature it trained on. The entity key is the decision people skip and it determines cost: pair features are the most valuable and the most expensive, stored sparsely with a default that is itself a modelling choice, and a composite key like user-and-category usually captures most of the signal for a fraction of the space. Discovery is the largest benefit and it needs usage counts and health signals to work. And keep on-demand features in the registry, because they are the ones most easily reimplemented differently in training.
Next: the three pipeline types and choosing between them per feature.