Course Overview
Every organization that plans ahead is forecasting something: a retailer deciding how much stock to hold before a promotion, a contact center staffing next month’s shifts, a ministry watching a leading economic indicator for early signs of a slowdown. Time Series Forecasting for AI Systems is a three-day capstone on doing that well — reading the structure in a series before you model it, choosing a model family that matches what the data actually looks like, validating it the way it will actually be used (forward in time, never peeking), and reporting a forecast with honest uncertainty instead of a single confident-looking number.
The official course description names three application areas, and this course is built around them directly rather than abstractly:
- Demand planning — how many units will sell, and where, so stock and logistics can be planned ahead of time.
- Workforce projections — how much staffing capacity a service will need, including the uncomfortable case where a past pattern stops holding.
- Economic indicators relevant to national programs — short, monthly, policy-relevant series where you have far fewer observations to work with and a cycle to reason about, not a season.
You will work with all three, plus one more case — intermittent, mostly-zero demand — that shows up constantly in real demand planning (spare parts, slow movers, long-tail SKUs) and that ordinary forecast accuracy metrics actively mislead you about if you don’t know to watch for it.
The four datasets
Every lab and every worked example in this course loads one of these four CSVs, all under data/. None of it is real — every number is synthetic, generated by data/generate_series.py with a fixed random seed — but each series is built to have the texture of the real problem it stands in for: a genuine trend, more than one seasonal period stacked together, a holiday effect that drifts on the calendar the way lunar-calendar holidays actually do, and (for workforce_demand.csv) a structural break that punishes a model that only ever saw the “before.”
| Dataset | Columns | Frequency & span | What makes it interesting |
|---|---|---|---|
retail_demand.csv |
date, region, category, units_sold |
Daily, 2023-01-01 to 2025-12-31 (3 regions × 2 categories = 6 series) | Trend + weekly seasonality (weekend lift) + yearly seasonality + drifting holiday-style demand bumps + sporadic 2–4 day promo shocks. The main running example for Days 1 and 2. |
workforce_demand.csv |
date, required_headcount |
Daily, 2024-01-01 to 2025-12-31 (1 series) | Trend + weekday-heavy weekly seasonality, plus a sustained ~35% step-change starting 2025-04-01 — a genuine structural break, used on Day 3 to show a model that backtested well fail after a regime shift. |
economic_indicator.csv |
month, activity_index |
Monthly, 2017-01-01 to 2025-12-31 (108 rows) | Short history, low frequency, a slow multi-year business cycle, and a sharp shock with a partial recovery. Forces you to reason with far fewer observations than the daily series give you. |
intermittent_demand.csv |
date, sku, units_ordered |
Daily, 2024-01-01 to 2025-12-31 (4 SKUs) | About 95% zero rows. Breaks MAPE outright (division by zero, or by numbers close to it) and motivates WAPE and a genuinely different model choice — the running example for objective 7, comparing model families. |
By convention, whenever a lab or a page needs “the” retail series and doesn’t say otherwise, it means Riyadh / Grocery — so the same numbers (a mean daily demand around 670 units, a clear weekly rhythm) recur from lesson to lesson instead of every example starting from scratch.
Everything in this course is generated, synthetic, and already in the repo. There is no dataset to request access to, no key to configure, and no external service this course depends on. data/generate_series.py is seeded — running it again reproduces the four CSVs byte-for-byte — so if you ever want to see exactly how a series was built, that script is the ground truth, not a black box.
The Setup covers running the labs, but the short version is: open a lab notebook in Colab and run the first cell. It installs its own packages and fetches the CSV and utility files it needs directly from this repository. Nothing to clone, nothing to install locally, unless you want to.
The tools, and why each one is here
The official course description names four libraries. Each earns a specific, non-overlapping job in this course rather than being four ways to do the same thing:
- statsmodels — the classical statistical backbone for Day 1: STL decomposition, the Augmented Dickey-Fuller test, ARIMA/SARIMA, and the exponential smoothing family (SES, Holt, Holt-Winters/ETS). These are the models with the longest track record, the ones whose assumptions you can actually check (residual diagnostics, AIC/BIC), and the right default when you have one series, or a handful, and enough history to estimate a proper seasonal model.
- LightGBM — the machine-learning approach on Day 2. Tree models don’t have any built-in notion of time or recurrence, so forecasting with one means engineering the time structure into features yourself: lags, rolling statistics, calendar features. In exchange you get a single model that can learn across many series at once (all six
retail_demand.csvseries, say) and incorporate exogenous signals a classical model can’t easily absorb. - sktime — a scikit-learn-style unified interface over many forecasting algorithms, used on Day 3 for its
predict_interval/predict_quantilesAPI: one consistent way to ask any forecaster for a prediction interval, rather than learning a different uncertainty API per library. - Prophet — an additive decomposable model (trend + seasonality + holidays, fit with a Bayesian backend) with uncertainty intervals built in from the start. Used on Day 3 as one of the model families in the comparison framework — strong when you have irregular holiday effects and want reasonable defaults with very little tuning.
The three days
Day 1 — Structure & Classical Models. Before fitting anything, learn to read a series: decompose it into trend, seasonality, and residual; read ACF/PACF plots to reason about autocorrelation structure; test for stationarity and difference when needed. Then fit the classical models that those diagnostics point you toward — ARIMA/SARIMA and the exponential smoothing family — and learn to compare candidates with AIC/BIC and check their residuals with the Ljung-Box test.
Day 2 — Machine-Learned Forecasting & Backtesting. Turn a forecasting problem into a supervised-learning problem: lag features, rolling statistics, calendar features, and the leakage traps that come with all three. Fit LightGBM on the engineered table. Then confront the question Day 1 mostly sidesteps — is one train/test split actually enough evidence that a model works? — with walk-forward backtesting: expanding and rolling windows, and the specific ways a backtest can leak information from the future without anyone noticing.
Day 3 — Uncertainty, Comparison & Capstone. A point forecast without a range around it is usually an overstatement. Build prediction intervals via quantile regression and pinball loss, get familiar with conformal prediction, and check whether an interval is actually calibrated (coverage and width, not just coverage). Then step back with a decision framework — given a series’ length, how many series you have, whether you need intervals, and whether the demand is intermittent, which of the four tools above is the right one to reach for? The capstone applies all of it to one real-world-shaped brief.
The Pre-Course Assessment has an ungraded pre/post knowledge check if you want to gauge where you’re starting from, and the Capstone: A Backtested Forecasting Report is worth reading early — it names exactly which of the next six lessons’ techniques your final report needs to demonstrate.
Continue to: Trend, Seasonality & Autocorrelation