Every ML team hits the same frustrating questions: "Which features did model v3 use?" "Can I reproduce last month's training data?" "I promoted a new model, which features does it need in production?"
The root cause is simple: feature stores and experiment trackers live in separate worlds. Features are managed in one system, experiments are tracked in another, and the link between them exists only in a data scientist's memory or buried in notebook comments. Teams try to bridge this with manual logging, custom wrappers, or naming conventions, all of which break the moment someone new joins.
In this talk, I'll share how we solved this in the open-source ecosystem by building a native integration between Feast (feature store) and MLflow (experiment tracker). The core idea: one line of configuration, and every ML experiment automatically knows exactly which features it used : with zero changes to your training code.
I'll walk through:
The real-world pain — why the disconnect between feature management and experiment tracking causes reproducibility failures, silent data drift in production, and operational blind spots.
The design philosophy — why we optimized for zero friction. No new imports, no decorators, no wrappers. If you're already using Feast and MLflow, the integration is invisible until you turn it on.
Model-to-feature traceability — how a serving pipeline can ask "which features does this model need?" and get a deterministic answer, instead of relying on hardcoded feature names that go stale.
The ops angle — how platform teams get an automatic audit trail of every data pipeline change without building custom tooling.