A fraud model scores 94% in testing and fails in production. The code is identical. The data wasn't.
avg_txn_30d was written twice. A data scientist defined it in a notebook against the warehouse — last 30 days, refunds excluded, v1 rules. An engineer defined it again in the service against the operational database — a rolling 30 days, a different refund filter, v2 rules. One name, two meanings.
So the model learns patterns from one version of the feature and scores against another. Nothing throws. It performs worse than it did in testing, and the gap stays invisible until somebody goes looking for it.
A feature store removes the second implementation. The feature is defined once — sources, filters, time window, business logic — and both paths read that definition. Offline it serves historical values as they stood at that point in time; online it serves the current value in milliseconds.
The point-in-time part matters as much as the sharing. Training on data that only existed after the event is leakage, and it flatters the model in precisely the way that fails later.
When the same idea is implemented twice, the question isn't whether they'll diverge. It's when, and whether anyone will notice.