SHUBHANKAR_TIWARI
← back to blog
June 18, 2026·6 min read

When Detection Works Perfectly and Recovery Doesn't

MLMLOpsDrift DetectionFraud DetectionSystems

I built a drift-aware fraud detection pipeline with automated retraining. Going into the project, I assumed that if drift was detected, the retraining pipeline would eventually recover from it.

What I learned was that detecting drift and recovering from drift are two entirely different problems.


The Setup

The model was an XGBoost classifier trained on the Kaggle credit card fraud dataset — 284,807 transactions, 492 frauds. Baseline AUC-PR was 0.824. Monitoring used KL divergence and Population Stability Index (PSI) on prediction distributions.

The workflow was straightforward: Drift Detected → Retrain → Shadow Deploy → Evaluate → Promote/Reject.

The governance layer evaluated candidate models against production using business loss, where a missed fraud is treated as 10× more expensive than a false alarm. It sweeps 50 thresholds to find the optimal operating point and rejects unstable promotions.

What Happened

I introduced a distributional shift in the input stream.

The monitoring layer detected it immediately. Retraining was triggered. A shadow model was created. The governance layer compared the candidate against production.

Result: no_change.

The candidate model came back with exactly the same metrics as production — AUC-PR: 0.824, AUC-ROC: 0.975, same precision, same recall, same business loss.

The governance layer correctly refused to promote the candidate model.

At first, that felt wrong. If drift was detected, why didn't retraining help?


The Bottleneck

The experiment exposed a limitation in the retraining workflow that I hadn't anticipated.

The retraining process was operating on the original training distribution. Even though drift was detected in production, the candidate model wasn't learning from the new patterns that triggered the drift event.

As a result, the retrained model came back with essentially the same performance as production. The system detected the problem correctly. The governance layer made the correct promotion decision. But the recovery process had no new information to learn from.


The Lesson

A drift pipeline isn't actually self-healing just because it can retrain.

Detection → Retrain → Evaluate → Promote sounds complete on paper. But recovery depends on something deeper: the flow of data back into the learning process.

In this project, every component behaved as designed. The experiment simply highlighted that a governance pipeline can work perfectly and still be unable to recover if the data architecture doesn't support recovery.

One thing I've noticed across multiple AI projects is that detection is often the easy part. The harder problem is building systems that can respond effectively once a problem has been detected.

In this case, the system knew drift had happened. It just didn't have the information needed to adapt to it.

That gap — between knowing something is wrong and being able to do something about it — is where a lot of the real engineering complexity lives. And it's not a gap you notice until you build the full loop.