What is the difference between a feature set and a feature store?

The set is a named list of fields; the store is the platform that computes, serves and versions them.

Should a feature set be minimal?

As small as held-out performance allows; every extra member is cost, risk and review surface.

Who approves a feature set change?

The model owner plus anyone accountable for the fields' meaning, typically a domain owner and, for sensitive fields, compliance.

AI Glossary / AI and machine learning / Beginner

Feature set

Definition

A feature set is the chosen collection of input fields a model uses: the full list of what the model may consider, selected, named and versioned as one unit.

What it means

Every model is built against a specific list of inputs, and that list is the feature set. It is a decision, not an accident: fields were included, excluded and defined, and the model inherits all three choices.

The set is the model's vocabulary. Two models trained on the same data with different feature sets are different models with different knowledge, even if every other setting matches.

Feature sets are shared and reused. A well-built set, customer behavior basics, say, becomes an asset that several models draw on, which multiplies the value of getting its definitions right once.

They are also versioned. When the set changes, fields added, dropped or redefined, every model using the old version is now running on history, and the version record is the only way to know.

For a business, the feature set is the natural unit of governance: review the set and you have reviewed what the model is allowed to know, which is most of what governance needs to check.

How it works

Assemble the candidate fields from available data and domain knowledge, then select the final list deliberately, recording what was excluded and why.

Define each member field precisely: name, type, source, transformation and owner, so the set is a document, not just a list.

Version the set as a whole: a change to any member is a new set version, and models record which version they consume.

Reuse sets across models where the underlying meaning is shared, and fork rather than quietly edit when one model needs a variant.

Review sets on a schedule: business change turns yesterday's well-chosen set into legacy, and the review is where that gets caught.

Three practical examples

A churn model and a win-back model sharing one customer-behavior feature set of 22 versioned fields.
A pricing model whose feature set forked from the standard set to add deal-specific terms.
A lender whose model registry records, for every model, the exact feature set version it was trained and validated on.

Think of it this way

Think of the set of tools a surgeon takes into an operation. The hospital owns thousands of instruments, but this operation gets a defined tray, counted before and after. The feature set is the tray: what the model works with, nothing more and nothing less.

The limit: a tray assembled for one operation is wrong for another. Reuse is valuable precisely because each set was assembled deliberately, and borrowing it for a new purpose deserves the same deliberation.

Worked example

versioning a shared feature set

Suppose a retailer's customer feature set, version 3, serves four models, and the data team wants to add a returns-behavior field. The figures are illustrative.

Adding it directly would silently change what all four models consume, so the team publishes version 4 with the new field and migrates models one at a time.

Each model is revalidated against version 4 before switching; one model, it turns out, degrades with the new field and stays on version 3 deliberately.

The registry now shows three models on v4, one on v3 with a note, and nobody had to discover any of this from an incident.

Illustrative case study

A fictional insurer let each project copy and edit the shared feature set informally, and within two years nine versions existed, none documented, each subtly different in how income was defined.

A regulatory review asked for the definition of income used in a two-year-old decision, and nobody could prove which variant had been live.

The invented lesson: an unversioned feature set is a definition you cannot defend. Version the set or forfeit the audit.

Common misconceptions and mistakes

The feature set is just the data columns. It is the curated, defined, versioned subset the model consumes; the raw data has far more columns and far fewer guarantees.
One set should serve all models. Reuse is good where meaning is shared, but forcing one set everywhere flattens real differences between decisions.
Sets are technical plumbing. They are policy: the set states what the model may consider, and that statement belongs in governance.

Business use

Name and version every feature set, and record which models consume which version, so changes are migrations, not surprises.

Review each set's member list in model governance, because the set is the complete answer to what does this model know.

Keep excluded-field notes with the set; the exclusions are often the most important sentence in the review.

Check your understanding

Why should a feature set be versioned as a unit rather than letting fields change individually?

Answer: Because models are trained and validated against the whole collection, so any member change silently alters what every consuming model knows unless the version records it.

Related terms

Learn next

AI for Business Owners explains how to govern what a model is allowed to know, starting with its feature set: https://aiforbusinessandlife.com/academy/ai-for-business-owners. [C2]

Sources

[S2] Google, Machine Learning Glossary. Full URLs are in the source ledger. Verified 11 October 2026.

Previous: Feature Selection Next: Feature shift