Shift attribution and incident triage

The alarm is real: estimated risk has crossed the tolerance and a labelled audit sample confirms the model is worse. The actionable question is not did something shift but which thing shifted, and is it mine to fix. The answers have completely different remediations. A broken upstream join is fixed in an hour by the data team. A genuine change in \(P(y \mid x)\) needs retraining and possibly a different feature set. A covariate shift into a thin region of the training distribution may need nothing at all except more data from that region.

Attribution as a decomposition

Treat the performance change as something to be allocated among candidate causes rather than diagnosed by intuition. Formulating it as a cooperative game and assigning each distribution's contribution its Shapley value gives a principled decomposition of a performance drop across shifts in individual covariates, the label marginal, and the conditional (Zhang, Singh, Ghassemi & Joshi, 2023, ICML, PMLR 202:41550-41578, arXiv:2210.10769). The practical value is not the exact numbers; it is that the decomposition forces the question "if only this had changed, how much of the drop would we see?", which is the question an on-call engineer should be asking anyway.

The triage order that resolves fastest

Cheapest and most likely first:

1. Is it data, not model? Null rates, row counts, schema versions, join fanout, timezone and unit changes, a feature that is now constant. Most incidents that present as model degradation are pipeline incidents, and validation systems built for exactly this have been deployed at production scale for years (Breck et al., 2019, Data Validation for Machine Learning, SysML).
2. Is it serving, not training? Training-serving skew, a stale feature-store materialisation, a model version rollback that half-applied, a preprocessing library upgrade.
3. Is it a segment, not the population? Compute the metric per slice. A 2% aggregate drop is often a 30% drop in one segment that grew, which changes both the diagnosis and the urgency.
4. Is the label pipeline healthy? Check arrival rate and maturity before trusting any metric computed from labels.
5. Only then: is it covariate shift or concept change? Compare risk restricted to the region the model was confident about before. If performance on stable, well-covered inputs is unchanged and the loss is concentrated in newly-common regions, it is covariate shift. If performance degraded on inputs that look exactly like last month's, the relationship moved.

Reproduce before retraining

Retraining is the reflex and it is often the wrong first move: it is slow, it destroys the evidence, and if the cause was a pipeline bug it bakes the corruption into the weights. Reproduce the failure on a frozen replay of the incident window first. Prediction logs joined to feature values and model version, which is what makes replay possible, are the single highest-value thing an observability stack stores.

When it breaks

Attribution is only as good as the candidate set. A cause you did not instrument cannot be assigned blame, and the decomposition will confidently distribute the drop among the causes you happened to log. Interview work with practitioners has consistently found that the deployed monitoring stack, not the modelling, is where production ML succeeds or fails (Shankar et al., 2022, Operationalizing Machine Learning: An Interview Study, arXiv:2209.09125). The corollary for triage: the incident you cannot explain is usually the one where the relevant signal was never logged, and the postmortem action is an instrument, not a model.