Weather data product design
A weather data product is more than the bytes. It's the access pattern, the documentation, the "timeliness", the validation that runs before anyone downstream sees a number. Everything that determines whether a researcher or engineer can build on it confidently.
We treat product design as a research problem: what makes a data product easy to use, fast, and reliable enough to depend on in production? What accelerates downstream experimentation? By asking and exploring these questions we endeavor to incorporate our finding into our own catalog and consuming projects.
Projects
-
Project →
Data Product Catalog
A public, live-updating catalog of cloud-optimized weather datasets.
-
Project →
Weather forecast production pipelines and observability
Arrival monitoring for the weather sources we depend on: when to expect each model run, whether today's run is on time, and a signed webhook the moment data crosses a readiness boundary — live at status.dynamical.org.
Notes & papers
-
2026 · Lab note →
Knowing the moment a forecast is ready
Forecast files don't arrive all at once — they trickle in over minutes or hours, on a cadence set by whoever produces the model. To stop guessing, we built wxopticon: a tool that watches upstream weather sources and answers two operational questions — when to expect a given dataset, and whether a run is on time relative to how that feed actually behaves.
-
2026 · Lab note →
Having it all: virtual and materialized data products
We want low-latency updates, completeness across variables and vertical levels, and fast access for both time-series and map reads — but at 14 PB and 1 billion GRIB messages, no single Zarr does it all. Virtual Icechunk Zarrs complement our materialized (rechunked) products: here's why we build them, how we update them within seconds of the source, and the lessons from getting there.