Time Series Fork

Loaded: fork-timeseries.md — chronological splitting, baselines, and lag construction.

Confidence flag — say this to the person once, at the start. Unlike the regression and classification paths, this fork is not grounded in a completed reference project. It's reasoned from principle. Treat it as a first draft: the structure is sound, but the specifics haven't been validated against a finished piece of work the way the supervised paths have. Verify anything load-bearing against course material or a known-good source before relying on it.

What changes from the standard spine

The default split is invalid here, and several sections shift.

No shuffled split, ever. Train on the earlier period, test on the later. train_test_split(..., shuffle=False) for a single holdout, or TimeSeriesSplit for cross-validation. A random split trains on the future to predict the past, which inflates every metric and produces a model that cannot be deployed.

Sort by the time index before anything else. Then check two things the standard spine doesn't: gaps in the series (missing periods), and duplicate timestamps. Both change what a lag feature means, so both must be resolved before any feature is built.

Univariate analysis is different. histogram_boxplot() on a time-indexed series says almost nothing useful. Replace it with:

• Line plot of the series over time — the primary chart.
• Rolling mean and rolling standard deviation, to see trend and changing variance.
• Seasonal decomposition (trend / seasonal / residual).
• An ADF test for stationarity, with the null stated explicitly: the ADF null is that the series has a unit root, i.e. is non-stationary, so a small p-value is evidence for stationarity. This is the wrong way round from most tests and is easy to invert under time pressure.

Feature construction must respect time. Lag and rolling features must never reference a row at or after the point being predicted. Build them with explicit shifts and verify by checking that the first rows come out NaN in the expected pattern. An off-by-one here leaks the answer directly into the features and produces suspiciously excellent results.

Metrics

MAE, RMSE, and MAPE (with the same zero-actuals guard as fork-supervised.md).

Always report a naive baseline alongside every model. Naive = predicting the last observed value; seasonal-naive = predicting the value from one full season ago. A model that doesn't beat the naive baseline isn't useful regardless of how its absolute error reads, and without the baseline in the table there is no way to tell.

Algorithms

Tree-based models work here — the change is in splitting and feature construction, not the algorithm. Random Forest on lag features is legitimate. Classical approaches (ARIMA, exponential smoothing) are a different family with different diagnostics; if they're in scope for the task, say plainly that this reference doesn't cover their diagnostic workflow rather than improvising one.