Causal forecasting and execution

Gridiron Oracle

Forecasts every NFL player's weekly stats from data known before kickoff, checks each new model against a frozen release before it ships, and runs signals through a C++ engine in under half a microsecond.

Python
C++
XGBoost
LightGBM
CatBoost
FastAPI
PostgreSQL
React

Live site Code

0.46µs
p99 message latency in the C++ ring
17–23×
lower p99 than a mutex queue
100M+msg/s
ring buffer throughput
74 of 75
stat-position seasons beat naive baselines, about 7% better MAE

How it works

Public NFL datanflverse
Validate and storePostgreSQL
Featuresonly the past
Four model typesGBDTs and a transformer
BlendRidge per stat, position
Release gatevs a frozen release
APIpinned results only
WebsiteReact
C++ enginelock-free ring, Kelly sizing

Public NFL data is validated and stored, turned into features that use only the past, and fed to four model types. A small linear blend per stat and position combines them. A frozen release gate decides what ships; the API serves only pinned results to the website, and a separate C++ engine handles fast simulation and bet sizing.

Decisions that matter

Only data known before kickoff
Every feature is built from games already played. Player form is tracked with a Kalman filter that only looks backward, so the model cannot peek at the result it is predicting.
Nothing ships without passing a frozen gate
A new model is compared against a frozen earlier release, and the server refuses any result whose fingerprint does not match what passed. That is how served predictions stay identical to the offline ones: all 80,404 rows checked match exactly.
Risk limits live in the engine
The C++ engine sizes bets at a quarter of the Kelly amount and caps exposure at 5% per player and 20% per game, so one bad forecast cannot sink the bankroll.

Results

My lock-free ring has a p99 17–23× lower than a mutex queue.

Lock-free ring
Mutex + std::queue
Dot is p50, tick is p99

Tap a rate

Cold open-loop latency, median of 3 reps (2 s warmup, 8 s measure, 30 s cooldown). Quote p50 and p99 only; p99.9 and max are scheduler tail. Apple M2 Pro, one machine; numbers do not transfer.

Latency as a table

Messages / s	Queue	p50 (µs)	p99 (µs)	p99 ratio
100k	Lock-free ring	0.12	0.5	18.3× lower
100k	Mutex + std::queue	6.29	9.13	baseline
500k	Lock-free ring	0.12	0.46	17.2× lower
500k	Mutex + std::queue	2.42	7.92	baseline
1M	Lock-free ring	0.12	0.46	22.8× lower
1M	Mutex + std::queue	1.29	10.5	baseline

Limits. In-season forecasts need games that have not been played yet, and the site says so instead of guessing. The engine is built and tested on its own; its link to a live odds feed was not verified.

Next projectMemory-constrained forecasting

Key numbers

How it works

Decisions that matter

Only data known before kickoff

Nothing ships without passing a frozen gate

Risk limits live in the engine

Results

My lock-free ring has a p99 17–23× lower than a mutex queue.