The engineering problem

Why disciplined evaluation mattered as much as the modelling, and why that is an infrastructure problem.

Collision parts are demanded only after an accident: unpredictable, intermittent, and volatile. Inchcape's Suzuki catalogue does not behave as one forecasting problem but as several at once. A small number of high-volume parts move steadily and reward conventional methods. A long tail sits idle for months, then spikes once, and punishes anything that assumes a trend. No single model wins across that spread.

Meeting that took real modelling work, and it made disciplined evaluation just as important. To find what actually works, the team had to build and compare many model families (classical intermittent-demand methods, regularised regression, gradient-boosted trees, a zero-shot foundation model) on genuinely identical terms. And they had to do it distributed across a nine-hour time difference, where any drift in how data is loaded, how folds are cut, or how error is scored quietly invalidates every comparison.

Two failure modes dominate work like this.

The first is inconsistency: each person fetching and shaping the data a little differently, so that results cannot be trusted against one another. The comparison looks like a comparison but isn't.

The second is leakage: information from the future slipping into training. It is the most common reason a forecast looks brilliant in testing and then fails in production, and it is especially easy to introduce when the rule that classifies each part is computed once over the whole history rather than at each point in time.

These are problems the platform exists to solve, not in place of the modelling, but so the modelling can move fast and be trusted. Solved once, centrally, they let the whole team work as one and keep the evidence sound; left to each notebook, they slowly poison the project's own evidence. That was the brief for the platform layer: make the correct thing the easy thing, make leakage structurally hard rather than a discipline each modeller has to remember, and free the team to spend its effort where the real difficulty lay: building models good enough to earn their place across a stubbornly varied catalogue.