Feature schema compatibility rollouts

A storage type widening or added optional field may be decodable by an older reader under some formats, but format compatibility does not prove feature compatibility. Changing units, category IDs, vector ordering, missingness, time windows, or entity normalization can invalidate a model while leaving a numeric payload readable. A default must have the meaning the model was trained to interpret; treating an absent risk score as zero can be materially different from a dedicated missing indicator. Check field presence and ordering at the actual model-input assembly point.

A feature bundle should resolve a declared set of schema, transformation, source, key, and preprocessing versions. A model deployment may support only some combinations. Avoid mutable active-definition lookups where a model requires a fixed revision. Registry caching and long-lived workers can create a mixed fleet even after a control-plane update succeeds. Log the resolved identities in validation requests and test old/new combinations explicitly. An application must reject an unsupported pairing instead of hoping a shared field name will cause the consumer to adapt automatically.

For an incompatible change, create a separate supported feature generation or namespace, backfill it, and keep both producer paths current while validating. Deploy a consumer that explicitly expects the candidate representation, compare its inputs and predictions on controlled traffic, then change routing according to a rollout policy. Retain the old representation and its compatible consumer for a defined rollback horizon. Reverting a schema pointer alone cannot recreate an old feature population if writers stopped maintaining it or a destructive migration erased its source interpretation.

Feast’s current versioning documentation labels the feature as alpha and describes backend limitations: version-qualified online reads currently require the supported SQLite path and configuration, rather than working automatically on every online store. Pin Feast v0.66.0 APIs and inspect deployed backend support before designing a migration around version syntax. Separate names or an application-managed generation can be necessary where built-in support is absent. A feature service groups model inputs, but registering it does not itself validate every consumer, prewarm every entity, or provide cross-store atomicity.

Build a compatibility matrix containing old producer with old consumer, candidate with candidate, and any mixed combinations that can occur during deployment. Test missing, null, boundary values, unknown categories, key aliases, stale registry caches, partial backfill, and fallback behavior. A shadow comparison should preserve each model’s intended input contract instead of feeding both models whichever representation is easiest to fetch. Monitor distributions, missingness, age, and resolved versions by deployment cohort, and make rollback prerequisites observable rather than a promise in release notes.

The sigmoid instrument illustrates a representation-and-consumer pairing. Reset, set both x=1 and w=1, predict σ(0.5)≈0.62246, then Play or Step. Separately Reset, set both x=2 and w=0.5, predict the same output, then Play or Step. For a third run Reset, set both x=2 and w=1, predict σ(1.5)≈0.81757, then Play or Step. The adapted coefficient preserves this toy computation while the mixed pairing changes it. This single fixed-bias unit does not migrate schemas or establish model equivalence beyond its stated arithmetic.