Lesson 2 introduced the train/test split: hold out data the model never sees during training, then score it there, to expose memorization masquerading as skill. That’s one estimate, from one particular split. K-fold cross-validation asks for several: split the data into k roughly equal folds, and run k rounds where each fold takes a turn as the held-out test set while the model trains on the rest — producing k separate error estimates instead of one, whose average (and spread) is a far more stable read on how the model generalizes than any single split could give.
More folds used for validation, not just one, means less of the estimate depends on which particular slice happened to become “the” test set — a real improvement over lesson 2’s single split, especially on smaller datasets where one unlucky split can badly mislead.
But cross-validation inherits, and can amplify, the same core risk lesson 2 first raised: the test fold has to represent data the model genuinely wouldn’t have access to at prediction time. Standard k-fold shuffles rows randomly before splitting into folds — a fine default for i.i.d. data (each row independent of row order), but not for every kind of dataset.
A model predicts next month’s sales from a dataset ordered in time. The pipeline runs standard k-fold, shuffling rows first. What breaks?