Specify Predictor Availability for Each Forecast Horizon

Introduction

A regression model can fit historical data well and still be unusable for forecasting. This happens when its predictors include information that was recorded after the time at which a forecast would need to be made. For example, a model intended to forecast tomorrow’s demand cannot use tomorrow’s realized weather simply because that value appears in a completed historical data set.

The relevant question is not only whether a variable exists in the data. It is whether its value would be known, in the form used by the model, when the forecast is issued. That answer can differ across forecast horizons. A weather forecast may be available for tomorrow but not for several months from now; a promotion may be scheduled for next week but not yet planned for next year.

Forecast Origins, Horizons, and Available Information

A forecast origin is the time at which a forecast is issued. The forecast horizon specifies how far ahead the target lies relative to that origin. If the origin is time \(t\), a forecast for the outcome at time \(t+h\) has horizon \(h\). For an outcome defined over an interval, such as visits during the next hour, the target interval must be stated as well as the origin.

Definition: The prediction-time information set at a forecast origin contains the information that has actually become available by the time the forecast is issued. A predictor is admissible for that forecast only if the value the model requires can be obtained from this information set, using the intended data process and cutoff.

The word available matters. A measurement can describe an event that has already happened but still arrive too late to use. Conversely, a value for a future date can be available if it was fixed in advance, as with the day of the week or a published schedule. Availability is determined by the time the value is known, not just by the time the value describes.

For a regression forecast at origin \(t\) and horizon \(h\), a general specification is

Y_{t+h}=\beta_0+\beta_1X_1(t,h)+\cdots+\beta_pX_p(t,h)+\varepsilon_{t+h}.

Here \(Y_{t+h}\) is the target, and each \(X_j(t,h)\) is a predictor value prepared for the forecast issued at \(t\). The notation permits the predictor set or predictor values to depend on the horizon. The central specification requirement is that each \(X_j(t,h)\) be computable using information available at the origin, including any future schedules or forecasts that are genuinely available then. This tutorial concerns that requirement, not how the coefficients are estimated.

Availability Depends on the Forecast Task

A variable name alone does not settle whether it belongs in a forecasting model. For every candidate predictor, ask what exact value the model would use, when that value is recorded or released, and whether it will exist at the forecast origin. Consider these distinctions:

Previously observed values: yesterday’s recorded demand may be usable today, provided it has been reported by the cutoff.
Current measurements: a measurement taken shortly before the origin may be usable if it is processed and available in time.
Known future values: calendar dates and a confirmed appointment schedule can be available for a future target period.
Future realizations: actual future demand, weather, or staffing are not available before they occur, even if they are present in retrospective data.
Delayed or revised records: a value can refer to a past event but still be unavailable at the origin because reporting or processing takes longer.

The specification must also match the intended use. A model for a forecast issued every morning may use information received overnight. A model intended to issue forecasts immediately when an event occurs may not. A predictor can be valid in one operational setting and invalid in another because their cutoffs differ.

Worked Example: A One-Hour Hospital Forecast

Suppose a hypothetical hospital wants to forecast the number of emergency-department visits arriving during the hour after 10:05 a.m. The forecast origin is 10:05 a.m., and the target interval is 10:05–11:05 a.m. Candidate predictors include the queue count recorded at 10:02, visits arriving during the target hour, and the number of visits recorded at 2:00 p.m.

The queue count recorded at 10:02 is available before the origin, so it can be considered as a predictor. In contrast, visits arriving from 10:05 through 11:05 occur during the target interval. Their realized count is the outcome itself, not information available for the forecast.

The 2:00 p.m. record is also too late. From 10:05 a.m. to 2:00 p.m. is \(14(60)-(10(60)+5)=235\) minutes, or 3 hours 55 minutes. It falls well after the 10:05 forecast origin and after the target hour ends. Including it would make the forecast depend on later information.

A suitable candidate specification might therefore use the queue count recorded by 10:05 and other timely predictors, but not either of the later visit counts. The exact eligibility of any additional predictor would require checking its measurement and reporting time against the 10:05 cutoff.

Worked Example: Retail Forecasts at Two Horizons

Consider a hypothetical retailer that issues a forecast at 9:00 a.m. on Monday. It wants to predict sales for the next seven days and, separately, sales for the week beginning six months later. At 9:00 a.m., the retailer’s calendar identifies the dates of both target weeks. A promotion for the upcoming week has been confirmed, but no promotion has been scheduled for the week six months away. Actual weather for either target week is not yet known.

For the next-seven-day forecast, the target week’s calendar and confirmed promotion schedule are available at the origin. They are admissible candidates. Realized weather during those seven days is not available; using it would substitute future observations for information available on Monday morning. If a weather forecast for that week is available at 9:00 a.m. and the operational system can supply it, that forecast—not the later realized weather—could be considered.

For the six-month forecast, the calendar remains known, but the upcoming-week promotion schedule cannot stand in for a promotion six months later. In this hypothetical setting, the later promotion is not scheduled at the origin, so its realized status is unavailable. A model for this horizon should not require that future promotion value. It could use the known calendar and other predictors whose values can be obtained at the six-month forecast origin.

Thus the two specifications need not have the same predictors. In shorthand, a short-horizon model might include \(X_{\text{calendar}}\) and \(X_{\text{confirmed promotion}}\), while the six-month specification might include \(X_{\text{calendar}}\) but exclude the unscheduled future promotion and future realized weather. The exclusion is about availability, not whether those variables might be associated with sales.

Worked Example: Weather Inputs for Energy Forecasts

A hypothetical utility issues forecasts at 8:00 a.m. It predicts electricity use for tomorrow and for the same date 30 days from now. Its weather service provides forecasts through 10 days ahead, and the historical data set also contains actual temperatures for every date. Assume the service’s forecast is delivered before 8:00 a.m.

For tomorrow, the temperature forecast is available at the origin. The relevant predictor is the service’s forecasted temperature for tomorrow, not tomorrow’s actual temperature. The latter is only observed after the forecast is issued.

For the date 30 days ahead, the service does not provide a forecast under the stated process. The actual temperature in the historical data is still unavailable at the origin, so it cannot be used merely because it is recorded retrospectively. The model for this horizon must omit that unavailable predictor or use a different temperature-related quantity that is genuinely available, such as a calendar-based historical normal calculated using information available at the origin.

The availability check therefore gives different conclusions for the same candidate field across horizons: the service forecast is usable for tomorrow and unavailable for the 30-day forecast. In both cases, the realized future temperature is excluded. Each conclusion depends on the specified service and cutoff; a different operational process could change what is available.

Why Future Information Must Be Excluded

The reason can be stated directly. A forecast issued at time \(t\) must be a function of information available at \(t\). If a model requires a value that will only be observed after \(t\), the forecast cannot actually be calculated as specified at its intended issue time.

Suppose two possible future paths have exactly the same information available at \(t\), but different realized temperatures at \(t+1\). A model that uses actual temperature at \(t+1\) can give different predictions for these two paths. Yet at time \(t\), the forecaster cannot distinguish the paths using the available information. The prediction therefore depends on knowledge not possessed at the origin.

This is the core of information leakage: information from after the forecast origin enters a predictor, directly or through a processed variable. When historical data are used to evaluate such a model, the evaluation can look better than a real forecast would be, because the model has been given hindsight. Excluding unavailable predictors is necessary for an evaluation to represent the intended forecasting task.

\text{Forecast at }t=f(\text{information available at }t), \qquad X_j(t,h)\text{ must be available at }t.

A useful practical consequence is that predictor values should be recreated as they would have appeared at each historical forecast origin. Replacing an original delayed or preliminary value with a later revised value can also introduce hindsight, even when both values refer to the same past event.

A Horizon-Specific Availability Check

Use the following sequence before retaining a candidate predictor in a forecasting specification. Repeat it for every horizon and every operational forecast setting; an answer for one horizon does not automatically apply to another.

Fix the forecast task.
State the origin, the target time or interval, and when the forecast must be issued. A vague phrase such as “predict future demand” does not define a usable cutoff.

Name the exact predictor value.
Decide whether the model would use a recent measurement, a lagged observation, a schedule, a forecast from another system, or a realized future value. These are not interchangeable versions of one variable.

Check its availability time.
Compare the time the value is recorded, released, processed, or confirmed with the forecast cutoff. Do not assume that a past event has been reported by the time the forecast is issued.

Make a horizon-specific decision.
Retain the predictor only if its required value is available for that horizon. Otherwise exclude it or define a different, genuinely available predictor for that forecast task.

Reconstruct historical inputs consistently.
For model development and evaluation, use values that would have been available at each historical origin, not later observations or revisions that were absent at the time.

Common Mistake: Treating a Historical Column as Forecast-Time Information

A common mistake is to reason, “The data set has actual weather for every date, so actual weather can be a predictor.” That conclusion confuses retrospective availability with availability at the forecast origin. The correction is to ask what information the forecaster could have obtained at that origin. For a future date, actual weather is not yet observed; a forecast from a service may be usable only if it was available then.

A related mistake is to create a single predictor list and apply it unchanged to every horizon. This ignores that a predictor’s availability can change with lead time. The correction is to document inclusion and exclusion separately for each horizon, including the source and timing of any forecasted or scheduled values.

Key takeaway: A predictor belongs in a forecasting specification only when the particular value required by that model can be obtained at the intended forecast origin. Check this separately for each horizon, and reproduce historical inputs as they would have been known then.

Check Your Understanding

For each question, identify the forecast origin and explain whether the proposed predictor is available at that time.

A forecast is issued at 6:00 p.m. for tomorrow’s deliveries. The dispatch schedule for tomorrow was finalized at 4:00 p.m. Can its scheduled number of deliveries be considered as a predictor? What should be checked before using it?
A model predicts next-day river level and uses the actual rainfall recorded during the next day. Explain why this is unavailable for a forecast issued the evening before.
A temperature forecast is available for targets up to five days ahead but not for targets 20 days ahead. Should the same temperature-forecast predictor automatically appear in both specifications?
A sensor measurement describes conditions at 9:50 a.m., but the data system releases it at 10:20 a.m. A forecast is issued at 10:00 a.m. Is the measurement available for that forecast? Explain.
Why can evaluating a model with actual future weather make its historical forecast performance appear better than performance in real use?