QM1.03 already taught the concept and named the danger precisely: shuffle a chronologically ordered dataset before a train/test split, and some "training" observations land after some "test" observations in real time, look-ahead bias, fixed with a chronological split or, more robustly, a walk-forward scheme. QD1.03 already built the machine that catches a violation of this inside a single backtest, mechanically, via no_lookahead's future-perturbation test, and named oos_split, walk-forward or purged cross-validation, with an honestly-counted trial total, as one of its own four harnesses. This module does not re-derive either. What it adds is the question those two modules never had to ask, because they each analyze one backtest, run once: on a schedule, which slice of history counts as "training data" this week, and how does that decision interact with promoting a freshly retrained model?
How do walk-forward splits work?
A pipeline that retrains periodically (weekly, say) needs a standing rule for exactly this, applied identically every single time, not reinvented by whichever researcher happens to be on call. Code pack exercise QD2.04-e08 (walk_forward_splits) builds that rule as a small, reusable generator: given a total observation count and a chosen train-window size, test-window size, and step size, it produces the full sequence of (train, test) index ranges a rolling retraining schedule will use, each pair constructed so that the training range's end can never be later than the paired test range's start, by construction, not by a check applied after the fact. That "by construction" property is exactly what makes the function trustworthy as scheduled infrastructure: a check bolted on afterward can be skipped under deadline pressure; a data structure that cannot represent an invalid split cannot leak, no matter who calls it or when.
Advertisement
What are purging and embargo?
One further refinement, real in López de Prado's work and worth naming even though this module does not build it as graded code, matters the moment a "label" used for training depends on future data relative to the observation itself, which is the ordinary case in finance: a label built from "the return over the next five trading days" observed at day i depends on prices through day i + 5. If a walk-forward split places the train/test boundary anywhere inside that five-day window, the last several training observations' labels reach into the test period even though the observations themselves do not, a subtler, later-discovered cousin of look-ahead bias that a naive walk-forward split, focused only on observation indices, would miss entirely. The fix is to purge those training observations whose label window overlaps the test period (illustratively: with a five-day-forward label and a training set ending at index 99, the observations at indices 95 through 99 all have labels reaching into index 100 or later, so all five must be dropped from training, not merely the boundary observation) and, more conservatively, to add an embargo of a few additional bars immediately after the split to guard against the same leakage running in the other direction across a later retraining cycle. Carry the concept; QD1.03's oos_split harness and QM1.03's walk-forward treatment are where the full machinery lives.