Back to the journal

Data engineering / 2 MIN READ

Forecasting starts with a data contract

A model cannot repair a time series whose meaning changes between rows.

Sai Sri Harsha Guddati ·

A forecast can arrive with a clean chart while resting on a poorly defined series. Before choosing a forecasting model, I want to know what each observation means.

My departmental data-science work includes Excel and PDF inputs, large tabular datasets, and TimesFM forecasting. Those ingredients make data preparation part of the modeling problem, not a preliminary chore.

Define the observation

An illustrative weekly service-demand series needs a consistent time interval, unit, and aggregation rule. Does a missing week mean zero demand or missing data? Did a category change its definition? Were historical records revised?

These questions influence the series before any model sees it. Filling a missing value with zero may create an artificial event. Combining categories with different meanings may produce a tidy number that no longer answers the original question.

The pipeline should preserve the choices made during cleaning and aggregation.

Separate observation from prediction

A chart should distinguish recorded values from forecast values. If uncertainty is available and appropriate to the method, it should be represented with its meaning explained. A precise-looking line should not imply a certainty the workflow has not established.

I would also make the forecast horizon explicit. A model evaluated for short horizons should not inherit an untested promise about much longer ones.

The user needs to understand the question the chart answers, not just admire its smoothness.

Evaluate in time order

A useful forecast evaluation respects the order in which information would have become available. An illustrative test can train or condition on an earlier period and assess a later one, repeating that process across several cutoffs.

A baseline matters. If a simple seasonal or recent-value approach performs similarly, the added complexity needs another justification. The result should explain errors in terms meaningful to the workflow, not only in terms of a convenient metric.

For me, the interesting work is making a forecast accountable to its input. The model contributes a prediction. The application contributes definitions, provenance, evaluation, and presentation. Without those pieces, an impressive chart can be a polished answer to a question nobody actually agreed on.

More from the journal