A reference architecture for hockey analytics
A full, opinionated blueprint tying data, models, AI and delivery into one system.
Sources
- APIs
- Scrapers
- Tracking
Lake / warehouse
- Bronze → silver → gold
- DuckDB / MotherDuck
Models
- xG, RAPM
- Reusable SQL/py
Serving
- Dashboards
- AI / MCP
- Reports
The 30-second version
- A good architecture separates raw data, models, and the question layer.
- Each layer can be swapped without breaking the others.
- AI and dashboards are consumers of the same governed gold tables.
Separate the layers on purpose
The core principle is decoupling: sources feed a lake, the lake feeds models, and models feed a serving layer. Because each boundary is a clean handoff (files, then tables, then marts), you can replace a scraper, switch warehouses, or add an AI consumer without rewriting everything downstream.
Govern the gold layer
The analysis-ready "gold" tables are the contract everyone builds on — dashboards, reports and AI agents all read the same governed marts. Document them, test them, and version them; that is what keeps answers consistent across humans and machines.
Treat AI as another consumer
An LLM like Claude does not get special data — it reads the same gold tables through a tool, exactly like a dashboard does. Keeping AI as a well-behaved consumer of the governed layer is what makes it safe and reproducible.
Build it yourself
- 1Sketch your four layers before writing code — sources, store, models, serving.
- 2Define the gold tables first; they are your contract.
- 3Wire one source end-to-end through all four layers.
- 4Add a second consumer (e.g. Claude) to prove the layers are decoupled.
Newsletter
Weekly hockey analytics
Data-driven takes on performance, scouting, and team strategy. No fluff — just the numbers that matter.
No spam. Unsubscribe anytime.