the experiment
As a Kwik Trip coworker, I use Kwik Trip's Kitchen Production System (KPS) daily. KPS forecasts how much food to make, but it doesn't account for the weather. Unusually high/low temperatures along with precipitation have a direct impact on customer turnout.
KitchenSync tested whether a weather-aware LightGBM forecast beats a KPS-style baseline. Both ran side by side on simulated stores for 34 days, compared on service level (customers who got food) and waste.
findings
service level
waste rate
days run
ML vs baseline, seeded by date
results by weather bucket
Bucketing simulated store-days by weather gives a cleaner read than daily A/B comparison. On extreme temperature days, ML beats the baseline by roughly 3x a neutral day gap, clear evidence that it's exploiting the weather signal the baseline can't access.
It's important to note that during simulation, daily temperatures were randomized and do not accurately represent seasonal changes. For example, Monday could be a high of 32° F (0° C) and Tuesday could be a high of 100° F (38° C).
| bucket | store-days | ml svc lvl | baseline | gap | ml waste | base waste |
|---|
While it can be noted that on rainy/snowy days the ML model's service level is a bit lower than the baseline's, overall waste is nearly half that of the baseline. Clearly, the baseline model over-suggests on rainy days and pays for it with higher waste.
On neutral days the picture flips: ML wastes more than the baseline. The model's edge comes from weather days, and on ordinary days it slightly over-produces.
daily results
service level %
waste rate %
how it ran
A POS simulator generated weather-shaped demand (Poisson arrivals, FIFO batches) into Postgres every 5 minutes. A nightly cron on EC2 rebuilt features and compared ML against the baseline, committing the results as JSON, which is what this page reads. A Streamlit dashboard showed the kitchen queues while it ran.
♜ stack ♖
languages
ml
simulation
db & storage
dashboard
infra
config & tooling