The shared platform

I set up the shared-library platform and built the Features API the team's modelling ran on. The implementation of the models themselves, and much of the code inside the library, was a team effort; the work described here is the scaffolding that made those models comparable, reproducible, and safe to trust.

A shared library

eptools gave every member of the team one way to load and prepare the data. Scoping, deduplication, hygiene checks, and the reindexing that distinguishes a genuine zero-sale month from a missing row were written once and reused, rather than reimplemented in each notebook. Across a team spread over a nine-hour time difference, that single source of truth was the difference between results that could be compared and results that merely looked similar.

A model contract

The core abstraction was a contract. Every model, however different inside, was wrapped in a function with the same shape: take data and parameters, return predictions in one agreed format. A naïve baseline, a classical intermittent-demand method, a gradient-boosted tree, and a foundation model all presented the same face to the evaluation harness. New models could be added with minimal boilerplate and, crucially, compared on identical terms. The contract is what let the team explore widely without the exploration collapsing into noise.

Evaluation without leakage

Models were scored through a rolling-origin backtest: step forward one month at a time, train only on the history available at that point, forecast at the real operational lead time, and pool the errors. The demand classification that routed each part was recomputed at every step using only past data, never the full history, closing the most seductive leakage path in this kind of forecasting. Making point-in-time correctness a property of the harness, rather than something each modeller had to remember, is what made the results trustworthy.

A Features API

Testing whether outside signals (economic indicators, fleet-size proxies, catalogue attributes) improve a forecast is easy to do badly. I built a Features API that turned exogenous data into a uniform, programmatic interface: list what is available, pull it as a frame, and join it to the demand panel on the right key without hand-written merges each time. That consistency mattered less for any single join than for what it unlocked next: the ability to test features at scale, automatically.