In a 14-day-ahead backtest, why put a 14-day gap between training and test data?

## The problem: labels have duration Most discussions of time-ordered evaluation stop at "train before the cutoff, test after it." That is necessary but not always sufficient, because the label attached to a training row is often *not* observed at that row's timestamp. Consider a supervised setup for a 14-day-ahead forecast. Row t holds features computed from information available at time t, and its label is the outcome 14 days later — either the value at t+14 for a direct h-step model, or the total over t+1 to t+14 for a cumulative target. Either way, the label is only knowable once t+14 has happened. Now stand at forecast origin T, the moment you would actually make the prediction in production. Which rows may be in the training set? Only those whose labels are already observed at T, that is rows with t + 14 <= T, or t <= T - 14. Rows dated between T-13 and T have labels that fall at or after T — outcomes that have not yet occurred at prediction time and which overlap the test window you are about to score. Including them is look-ahead, and it is created purely by the split, independently of how the features were built. So the training set ends 14 days before the origin, the test window begins after the origin, and between them sits a gap of the horizon length. The gap is also called **purging** — removing training rows whose label windows overlap the test period — and **embargo** when an additional buffer is placed after the test window before training resumes at the next origin. ## The second reason: boundary correlation Even when labels are technically observed, the rows immediately adjacent to the cutoff are the most similar to the first test points: nearly the same level, the same weekday context, often the same promotion or weather. Fitting on them lets the model approach the test window from arm's length rather than from genuine distance. A gap removes the most-correlated rows and makes the reported error closer to what you will see in production, where the newest usable data is already stale by the time it is processed. ## When the gap is unnecessary The gap is not a ritual. It follows from the target definition and the data-availability schedule: - **Plain one-step-ahead fitting on the series itself.** If you estimate a model on observations up to T and forecast T+1, every value used in the fit is already realised at T. There is no unobserved label and no gap is required. - **Recursive multi-step forecasting.** The model is still trained one step ahead and then iterated forward, so training labels are all observed at T. The horizon is produced by iteration, not by a forward-dated target, so again no gap. - **Direct multi-step or window-aggregate targets.** Here the gap of the horizon length is required, because the target explicitly reaches forward. The test to apply is mechanical: for each training row, ask what date you would first have known its label. If that date is on or after the origin, the row must go. ## Data-availability lag Production rarely has data up to the instant of prediction. Sales may settle for three days, returns may be reconciled weekly, a third-party feed may arrive with a delay. If the freshest reliable observation at origin T is from T-3, then your backtest must also cut features at T-3, and the label constraint compounds: training rows need t + 14 <= T - 3. Backtests that quietly assume instant data are one of the most common sources of an optimistic number that evaporates on deployment. Where possible, reconstruct what was *known* at the origin, including the vintage of any revised series, rather than what is known today. ## What the gap costs You lose horizon-many rows of training data at every origin, and the reported error goes up. Both are features, not bugs: the lost rows are the ones you would not have had, and the higher error is the honest one. If losing them materially hurts the fit, the real message is that the history is short relative to the horizon, which is itself worth reporting. ## Interview framing State the rule as a consequence rather than a recipe: training may use only labels that were observed at the forecast origin; when the target reaches h steps forward, that removes the last h rows, which is the gap. Add the availability lag, add the boundary-correlation argument as a secondary benefit, and note the case where no gap is needed so it is clear you are reasoning rather than reciting.