Shared Data or Feature Store¶
Software / tool — instantiates Shared-Input Variety Platform Design
Allows multiple analytics, machine-learning, or information products to use governed common data or feature inputs.
A Shared Data or Feature Store serves a governed set of data features to many analytical or machine-learning outputs, so that every model consuming a feature gets the same validated, versioned, lineage-tracked input — and it carries an explicit register of the correlated risk that one bad feature can silently corrupt every model downstream of it. Its defining move is serving a live shared input that many consumers use as-is, with each model's own validation left at the boundary. Unlike a shelf of parts you recombine, the store is one governed source feeding many mouths; its central design problem is that the sharing which gives consistency also concentrates failure.
Example¶
A bank runs several models — credit-risk scoring, fraud detection, and marketing propensity — and each team independently computes features like "estimated income," "account tenure," and "recent transaction velocity" from raw tables, with subtly different definitions and three duplicated pipelines. The bank builds a feature store. Each shared feature is registered with a definition, a version, and lineage; models subscribe to features instead of recomputing them. A coupling-risk register notes that "estimated income" now feeds three models at once, so a bug or drift in it has a wide blast radius — the store adds monitoring and a rollback path sized to that exposure. Meanwhile fraud detection's need for point-in-time-correct features (to avoid leaking future information) stays fraud's own responsibility: model-specific validation lives at the boundary, not in the shared store.
Outcome: one agreed definition of each feature, one place to fix a bad one, and a named owner watching for the correlated failure that shared inputs invite.
How it works¶
- Maintain a governed inventory of shared features, each with a definition, version, and lineage, and a mark on which are unsafe or misleading to share.
- Serve features as subscriptions, so consumers draw a governed input rather than recomputing their own divergent copy.
- Register correlated-failure risk by blast radius — how many models a feature feeds — and add monitoring, validation, and rollback in proportion.
- Keep model-specific validation at the boundary. The store governs the input's integrity; whether that input is fit for a given model's context remains the model's own check.
Tuning parameters¶
- Governance strictness — how much definition, lineage, and validation a feature needs before publication. Stricter is safer but slows the addition of new features.
- Freshness / latency — batch versus real-time serving. Fresher features cost more and raise the risk that training and serving diverge.
- Sharing bar — which features are safe to share versus kept local; some features are context-dependent and mislead when reused blindly.
- Drift monitoring depth — how aggressively served features are watched for distribution shift.
- Access and versioning policy — who may consume a feature and how version changes are rolled out to subscribers.
When it helps, and when it misleads¶
Its strength is consistency: one definition of each feature across every model, far less duplicated pipeline work, and a single place to correct a bad input rather than chasing copies through many teams. For a portfolio of analytics products drawing on the same underlying data, it is how common inputs stop being silently re-derived.
Its failure mode is the shadow of its strength — a bad or drifting shared feature propagates to every consumer at once, turning a local bug into portfolio-wide, correlated failure. A related trap is training–serving skew,[n1] where the feature a model sees in production differs from what it trained on. The classic misuse is sharing a feature that is actually context-dependent — one that leaks target information in a particular model's setting — so that "reuse" quietly injects the same subtle error into many models. The guarding discipline is to size the coupling register by blast radius, monitor for drift, and keep each model's own fitness validation local rather than assuming a governed input is automatically appropriate.
How it implements the components¶
shared_input_inventory— the versioned, lineage-tagged catalog of shared features is the inventory of reusable inputs, including the flags on which are unsafe to share.coupling_risk_register— it records which feature feeds how many models and the blast radius of a defect, attaching validation and rollback proportional to that exposure.variation_boundary— it draws the line between the shared, governed input and each model's own point-in-time and fitness validation, which stays local.
It does not package recombinable capability blocks behind composed interfaces (common_capability_layer, interoperability_contract, reuse_onboarding_path — that is its nearest twin Modular Capability Library); the store serves one governed input that models consume as-is, whereas the library hands you blocks to assemble into new outputs.
Related¶
- Instantiates: Shared-Input Variety Platform Design — the store is the governed common-data organ of the shared layer.
- Consumes: Platform Governance Board sets the semantic-governance standards the store enforces on its features.
- Sibling mechanisms: Common Platform Roadmap · Cross-Output Cost Attribution Model · Joint Procurement or Tooling Pool · Modular Capability Library · Platform Governance Board · Product-Line Architecture · Reuse Intake and Fit Assessment · Shared Service Catalog · Stovepipe Retirement Migration Plan
Editorial Notes¶
Form Classification¶
Form family: Structure, Architecture & Configuration
Rationale: Shared Data or Feature Store operates as a configured physical, technical, or logical arrangement whose structure creates the effect because it allows multiple analytics, machine-learning, or information products to use governed common data or feature inputs.
Independent corroboration: The frozen evidence defines Shared Data or Feature Store as 'Allows multiple analytics, machine-learning, or information products to use governed common data or feature inputs', so its operative form is Structure, Architecture & Configuration.
Nearest alternative: Record, Log & Register — Shared Data or Feature Store includes features of a persistent ledger, log, register, or case record that preserves history and traceability, but its defining operation is a configured physical, technical, or logical arrangement whose structure creates the effect.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Data Science & Analytics
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: A governed shared store for reusable model features is a machine-learning data-platform mechanism. Uber's Michelangelo introduced a production feature store and Google documents shared feature management; computer science supplies serving infrastructure and information science contributes stewardship.
Related originating lineages:
- Computer Science & Software Engineering — Storage, serving, lineage, and consistency infrastructure make common features reusable online and offline.
- Engineering & Design — Engineering design, reliability, and systems-safety practice supplies a parallel or contributing lineage for the mechanism's defining operation: allows multiple analytics, machine-learning, or information products to use governed common data or feature inputs.
- Library & Information Science — Metadata, provenance, and controlled definitions preserve discoverability and shared interpretation.
- Organizational & Management Science — Data ownership and stewardship govern access and accountability across product teams.
Review resolution: The blind reviewers disagree on primary lineage (data_science versus computer_science). Authoritative or primary research supports data_science as the best historical origin: A governed shared store for reusable model features is a machine-learning data-platform mechanism. Uber's Michelangelo introduced a production feature store and Google documents shared feature management; computer science supplies serving infrastructure and information science contributes stewardship. The cited Uber Engineering, Michelangelo Machine Learning Platform; Google Cloud, Vertex AI Foundations and Feature Store directly supports the mechanism's defining operation. All independently supported contributing domains are retained without an arbitrary cap. origin_mode=cross_disciplinary_synthesis records the lineage relationship, while domain_reach=multi_domain records later applicability separately from provenance.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
- Uber Engineering, Michelangelo Machine Learning Platform
- Google Cloud, Vertex AI Foundations and Feature Store
Notes¶
[n1] Training–serving skew — a machine-learning failure (documented in Google's Rules of Machine Learning) where the feature values a model sees in production differ from those it trained on, degrading predictions. A shared feature store reduces it by serving one definition to both training and serving — but a mis-governed store can also propagate the same skew to every consumer at once. ↩