The One Idea Worth Stealing From Foundation Forecasting
Chronos, MOMENT, and Moirai made forecasting feel like a language modeling problem, which is a fun trick but a heavy way to ask "what usually happens after a week that looks like this one." chronopatch keeps that one idea and throws out the billion-parameter checkpoint: similar recent patches predict the next patch.
The synthetic demand series has trend, seasonality, promotions, and drift, which is enough to expose a lazy seasonal baseline while keeping the whole benchmark reproducible on a laptop.
A Point Forecast Without Uncertainty Is A Guess In A Lab Coat
The forecaster retrieves historical contexts that look like the current one, averages what came next, and blends that with a recent trend correction.
Then it calibrates residuals on held-out data and wraps the forecast in a conformal interval. That interval is not decoration. Ship a forecast with no honest uncertainty band and the person reading it has to invent one, badly, usually at 2am.
The Number
Seasonal naive, the thing most dashboards do by default without telling you, scores 1.167 MASE. chronopatch scores 0.987, a 15.44% relative gain. Its conformal interval actually covers 93% of test points instead of just claiming to, with a mean width of 15.11.
The Series That Proved the Point Was Built to Prove the Point
I went back and checked exactly what that synthetic demand series contains. Weekly seasonality, a seven day cycle, baked directly into the data generator. And the forecaster's default season length, the number it uses to decide what "last week" even means, is hardcoded to exactly seven. The benchmark was asking the model whether it could find a seven day pattern in data built to have a seven day pattern. That is not nothing, but it is not the whole story either.
There is a second problem sitting right next to it. The 93 percent coverage claim rests on 14 test points. Fourteen. The honest confidence interval on that estimate spans roughly 79 percent to 100 percent, which means the tidy two decimal places in the published number are implying a precision the sample size simply cannot support.
So I ran the same measurement two ways. Across 40 different seeds of the exact same series family, the roughly 19 percent gain and 0.91 coverage held up completely, not a lucky draw on one particular seed. Then I built a second series with the same overall shape, trend, a periodic component, noise, but monthly seasonality instead of weekly, no promotion spikes, no discrete level shift, and about four times the noise relative to signal. Equally plausible as something you would actually see, just built without the model's own assumptions baked in.
On that series the mean gain fell from 19 percent to single digits, and a real share of runs went negative, the patch method actually doing worse than plain seasonal naive. Coverage dropped well under the 90 percent target on some seeds too. I even tried manually correcting the hardcoded seven day season to the true thirty day period on the harder series, and it did not reliably fix things either. The patch matching idea itself does not transfer cleanly to a noisier, less repetitive signal, correcting one hardcoded number was never going to be enough.
Nothing about this is a code bug. The forecaster and the benchmark do exactly what they say, and the published numbers still reproduce exactly. It is an honest scope statement the original single series and 14 test points never gave you: this method's real strength is on data that looks like the series it was tuned against, and knowing where that edge actually ends matters more than one clean headline number.
15 tests pass locally and on GitHub Actions across Python 3.9, 3.11, and 3.13.