Feature pipelines need contracts too
Chapter 37 put contracts on raw data. Features deserve a stricter one — because the feature vector is the interface between the data world and the model, and both training and serving must honor it identically or everything downstream is quietly wrong.
What a feature contract pins down
Run the editor. Per feature: name, type, valid range, null policy — plus, in the document if not the code, its definition ("logins in the 30 days before the prediction time" — with chapter 36's cutoff rule built into the sentence) and its owner. The checker runs in two places: at the end of the training pipeline, and in front of the model at serving time. Same contract, both sides — that symmetry is the whole point, and next lesson shows what happens when it breaks.
Versioning features like code
Features change — a bug fix in the aggregation, a new window, a
renamed column. Every change shifts what the model sees, so
feature definitions get versioned (logins_30d_v2), and a model
records which versions it trained on (the registry lesson makes
this concrete). The failure this prevents: silently "improving" a
feature under a deployed model, which is retraining the world
while the model stands still.
This is also the real scope of the buzzword feature store — a system that computes features once, serves them consistently to training and inference, and tracks definitions/versions. Whether you adopt one or hand-roll with chapter 37's pipelines, the contract and versioning are the part you can't skip.
Where AI specifically gets this wrong
- Features defined twice. One implementation in the training notebook, a "matching" one in the API server. They drift; next lesson is the autopsy.
- Contracts on raw data only. The raw contract passed, then a buggy transform produced negative login counts — which the editor's checker just caught and yours should too.
- Unversioned feature changes. "We fixed the feature" + deployed old model = a skew you inflicted on yourself.