Sharing Feature Definitions Across Training and Online Serving

An anonymous financial-services engagement using Feast, a feature registry, historical data and Redis-backed online access, with training and serving semantics kept...

Repeated feature work hid different meanings

Model teams at a financial-services company maintained separate feature pipelines for credit, fraud and personalization use cases. Similar features were computed differently, and the training and serving paths did not share the same responsibilities. Reusing a feature name was not enough to establish that two models received the same meaning.

Ampity built a shared feature-store foundation using Feast with custom extensions. Its design separated feature definitions and metadata, historical feature values and online access. Batch computation used Spark, stream computation used Flink, and Redis supported the online store.

Share a definition without pretending the stores are identical

The registry gave feature definitions and metadata a common home. The offline store retained historical values for training-related retrieval, while the online store supplied values for inference. Those roles needed to stay distinct even when they referred to the same feature.

A definition can align a transformation's meaning without proving that each path used the same inputs, timing or revision. A late event, changed entity key or revised default can still make the values differ. The actual feature-version, time-join and materialization settings remain unspecified in this case.

Current Feast online-store documentation describes latest values per entity rather than historical values. An online read should therefore not be used as evidence of what a model could have known at an earlier prediction time.

Keep platform ownership proportional to the need

The options included a vendor-operated feature platform, a shared code library and an open-source foundation with custom work. The selected Feast-based approach kept data-handling and extension choices with the engineering team.

A shared library could reduce duplicated transformation code but would leave online access and historical retrieval as separate operating problems. Building a platform introduced its own responsibility for the registry, stores, computation and adoption. Neither choice automatically establishes governance or better predictions.

Data access, personally identifiable information and decision traceability were requirements of the financial-services setting. They were not benefits to assume from a feature-store product name. A comparable project needs explicit owners for access policy, retention and feature use.

Adopt through a model team before requiring a platform

The rollout began with a model team involved in shaping the platform, followed by optional adoption by other teams. That approach made feature reuse and the needs of existing models part of the design conversation.

For a new migration, preserve the current model's input contract before changing where a feature comes from. Compare entity keys, transformations, defaults, freshness and missing values. Moving to a common store is not permission to retrain a model, change its threshold or redirect live decisions.

An empty result, a deliberately recorded zero and a stale value need different handling. The consumer must know which states it can accept and when to stop or use an approved fallback. This is a proposed acceptance boundary, not a claim that a particular fallback was deployed here.

Review one feature at one prediction time

Use authorized read-only inspection of existing definitions, sanitized feature samples and model input contracts first. The worksheet below is proposed guidance for a comparable platform, not a completed test record from this engagement.

Any later replay or migration rehearsal needs an approved isolated environment, sanitized data, restricted identities and disconnected credit, fraud and customer-action receivers. Bound data volume, runtime and spend. Stop on unexplained feature differences, unauthorized data or an output path that can affect production.

Restoring a previous definition or store path changes subsequent reads. It does not undo decisions already made from an incorrect value, and a replay can overwrite newer online state if its publication rules allow it. Keep downstream correction and online-write authority explicit before scheduling a replay.

Scope without a latency or productivity benchmark

This case describes the shared feature-store foundation and adoption approach. It does not publish serving throughput or latency, eliminated skew, productivity gains, model-quality improvements or a verified regulatory-control result.

Separate feature availability from model quality

Take one feature used by one model and reconstruct its meaning and availability at a named prediction time before expanding the migration. A correct value retrieval is an input check; it does not establish that the model made a useful or fair decision. The model-monitoring case addresses the separate problem of investigating predictions while outcome evidence arrives.

Technical reference

Feast's point-in-time join documentation describes historical retrieval relative to each entity timestamp and a TTL. Its current guidance also distinguishes event time from when a backfilled value became available, with availability filtering dependent on supported configuration. Check the actual Feast version, offline-store support and timestamp meaning before claiming that a training join reproduces an earlier online view. This case does not claim that such a test or filter was delivered.