Deploying a forecasting service

Today we're looking at what it actually takes to hand a forecasting model over to another piece of software, one that will call it every single morning with nobody standing by to catch a mistake.

Birchwood Grocers runs 4 grocery stores. Every morning, its replenishment system decides how much fresh milk to order for the next delivery truck, and for store 4 that decision leans on a forecast of how many cartons of milk the store will sell. The store has 730 days, two full years, of daily sales on record, starting 2024-01-01.

Here is the last 70 days of that record, the part closest to today.

Notice the ridge-and-valley pattern: cartons dip during the week and jump on weekends, while the whole line drifts upward, a little higher every week, across those 70 days. Somewhere, every single morning, something has to ask for tomorrow's number, safely, with nobody checking it by eye.

What changes when a machine asks instead of a person

Picture the forecast living the ordinary way first: as a script, forecast.R, that an analyst runs by hand each morning. They open it, run it, and glance at the number before sending it anywhere. If the date looks wrong, or the number comes out negative, they notice, and they fix it before it reaches anyone.

Now picture Birchwood's actual setup: the replenishment system calls the forecast automatically, at 6am, with nobody watching. Nobody glances at the number. Nobody notices if the date was typed wrong. Whatever comes back gets used to decide how much milk gets ordered.

That difference, a person in the loop versus nobody in the loop, is what changes when you serve a model instead of running it by hand. Three things that the analyst's habits used to cover for now have to be built into the service itself.

1. A fixed shape for what goes in and what comes back, a request and a response, agreed on in advance, since the caller is code and code cannot read a column header to work out what a number means.
2. Handling of bad input, since nobody is there to notice a typo or a nonsense request before it reaches the model.
3. Being available whenever the caller asks, with nobody around to restart it if it falls over overnight.

A contract, handling bad input, and staying available: those three things are what turn a fitted model sitting in an analyst's R session into a forecasting service.