How does a centred rolling mean feature leak future values into a training row?

## The rule being violated Every feature on a training row must be computable from information that exists at the forecast origin — the moment the prediction would actually be made. Training is meant to simulate production. If a column uses information that will not be available when the model runs, the model learns a relationship it cannot exploit, and the evaluation measures a task nobody asked for. That is **look-ahead leakage** in feature construction. It is distinct from leakage introduced by how data is split for evaluation; here the column itself is unbuildable in production, so no evaluation scheme can rescue it. ## Why centring is the classic case Smoothing is a natural instinct: a noisy series is easier to reason about once averaged. Centred windows are the default in a lot of visualisation and smoothing work because they do not shift the curve sideways — a trailing mean lags the series by roughly half its width, while a centred mean sits on top of it. That property is exactly what makes it a good picture and a fatal feature. A centred window of width `w` at time `t` covers `t - (w-1)/2` through `t + (w-1)/2`. At `w = 7` that is `y[t-3]` through `y[t+3]`. Three observations are future relative to `t`, and `y[t]` itself is in the average, so the feature contains a fraction `1/7` of the exact target. A model with any capacity finds that relationship immediately: multiply the smoothed column by seven, subtract the neighbours it can partly infer, recover the target. The symptoms are consistent. Training and validation error land far below any sensible benchmark — better than a domain expert believes possible. The smoothed column takes an overwhelming share of feature importance. Removing it destroys performance in a way no legitimate feature does. Then the first production week reports errors several times the validation figure, because the column is now built from whatever the pipeline does when half the window is missing: a shorter window, a forward fill, or nulls. ## The fix Use trailing windows only, and offset them by the horizon. For a forecast made `h` steps before the target, the window ends at `t-h`; compute the trailing statistic and then shift it back `h` steps. A next-day model may use a window ending yesterday; a fourteen-day-ahead model may not, and needs its own feature table. The general audit is a single question asked of every column: *what is the latest timestamp any input to this number carries, and is that timestamp at or before the forecast origin?* If the answer is later than the origin, or if you cannot answer at all, the column is not admissible. Doing this column by column is tedious and catches nearly everything. ## The neighbours of this bug **Interpolating a missing target across a gap.** Linear interpolation between the last observation before a gap and the first one after it computes the filled values from data on both sides. Every interpolated row therefore contains information from after itself, and if those rows are used as targets or as inputs to lags, future information propagates through the table. Filling forward from the past is different in kind — it uses only earlier data — but carries its own hazard: if a missing target is filled with the previous day's value, that row's target becomes exactly its own lag-1 feature, and the model learns to copy. Metrics improve on rows that were never real observations. The honest handling is to mark gaps explicitly, exclude imputed rows from the target, and carry an observed flag. **Statistics computed over the whole history.** A per-series summary — the mean level of an item across the entire dataset, the item's peak, a ranking of items by total volume — computed once over all rows and joined back gives every training row a summary of its own future. The correct form is expanding: for the row at time `t`, the statistic is computed only from data strictly before `t` (or before `t-h`), so it evolves along the series exactly as it would in production. **Aligning an external series at the wrong timestamp.** Weather, prices and promotion calendars are often stored by the date they describe rather than the date they became known. A promotional discount recorded against its effective date is a legitimate feature if the plan was locked in beforehand, and leakage if it is a value only known after the fact. Store the timestamp at which each fact became knowable, not only the timestamp it refers to. ## Interview framing This question is a filter for people who have shipped a forecast rather than only fit one. Weak answers say leakage means "including the target in the features" and stop. Strong answers describe the mechanism precisely, name the diagnostic signature — implausibly good validation error, one dominant column, a large live-versus-offline gap — and give an operational rule for prevention rather than a promise to be careful. The best answers add that suspiciously good results deserve the same investigation as suspiciously bad ones, which is a habit, not a technique.