Detect and Recover Data Drift

Working copy is not recorded truth

Here's a scenario that catches people who assume Git alone is enough: someone edits a data file directly after it was already dvc add-ed, without going through the proper DVC workflow. Git, which only ever tracked the small pointer file, may report "no changes" - as far as Git is concerned, nothing it tracks has moved. But dvc status will correctly report drift: the actual data sitting in the workspace no longer matches the checksum recorded in the pointer. This is exactly the same underlying idea as the ML distribution drift covered earlier in the foundations phase, just applied to a raw data file's content instead of statistical properties.

The first and most important step when you discover drift is to figure out why it happened before doing anything else. If the edit was genuinely intentional - someone deliberately updated the dataset and simply forgot the DVC step - the fix is to re-run dvc add and commit the new pointer, exactly as in the normal workflow above. If the edit was not intentional - a bug corrupted the file, or someone edited the wrong path by mistake - the fix is instead to restore the last known-good version from DVC's local cache, discarding the accidental change.

Warning: Do not reflexively run dvc add the moment you notice drift during an active incident, before you've confirmed which direction the fix should go. Doing so would happily record damaged or even maliciously poisoned data as the new "correct" version, permanently baking the incident into your data history. Compare checksums, inspect an actual diff of the file or a validation report, and clearly identify the authoritative version - the one everyone has actually agreed is correct - before touching anything.

Goal: In the data-drift lab, you'll restore the approved dataset and demonstrate that Git and DVC agree with each other again - proof that the drift has been correctly resolved rather than just papered over.