Click any component to explore it in the full case study.

LightGBM Recursive Multi-Step Forecasting
Step 1
Feature Assembly
Time features, lag (15m/30m/1hr/24hr/7day), rolling (1hr/4hr mean/std/max/min), weather, park schedule context. One global model for all attractions.
Step 2
Predict Horizon 1
LightGBM predicts 15-min ahead. max(0, predicted) clamp. Prediction appended to live buffer as if observed.
Step 3
Recursive Steps 2–7
Each predicted value becomes the lag input for the next step. 30m, 60m, 90m, 120m, 150m, 180m predictions built on prior predictions.
Step 4
Output Dict
{prediction_datetime → wait_seconds} for 7 horizons. One dict per entity.
⚠️ Why This Was Abandoned (Lesson)
Recursive lag imputation caused compounding error. By the 3-hour horizon, the buffer was entirely model-generated — not observed data. No real lag features at inference. Error accumulated multiplicatively. v8 (Prophet per-ride models) addressed this by eliminating lag features entirely and using temporal decomposition instead.
['Error accumulation at 3hr horizon', 'Buffer = model-generated by step 5+', 'No real lag at inference time', 'Single global model (all attractions)', 'Informed design of v8 (Prophet per-ride)', 'Lesson: recursive imputation is a trap']
ride-whisperer-v6.html#recursive forecasting
1
Global model (all attractions)
7
Forecast horizons
6hr
Lookback window
v6
Iteration
StackLightGBM (GBDT)PostgreSQL Flexible ServerPythonThreadPoolExecutorpsycopg2Pickle model artifactsKISM METAR