WeatherBot
Building a record of what the market could know.
What was known. And when.
When the observation happened
When the collector first saw it
What the research could know
Quality gates precede paper entry · architecture illustration
Overview
WeatherBot combines a historical weather-market backtest, prospective public-data recorders, a research dashboard, and a persistent paper engine. The core concern is provenance: what observation and what market depth were actually available at a decision time?
Problem
Weather markets depend on exact stations, local dates, bucket boundaries, rounding, and resolution sources. A later corrected observation or an incomplete order book can make a historical opportunity look more executable than it was.
Approach
Keep collection, point-in-time normalization, research, and paper execution behind separate boundaries. Retain original observations and local receipt times, validate each event’s rules, and expose missing evidence instead of filling it with market-implied guesses.
How it works
The NYC recorder discovers the exact Gamma event, validates the KLGA station and outcome partition, and subscribes to the YES-token level-two books. It records the complete received depth alongside distinct weather observations and their first-seen timestamps.
The multi-city paper runbook extends monitoring to NYC, Chicago, and Toronto. Local dashboard and Windows desktop modules provide collection controls, health views, and paper-account visibility.
- 01Weather & CLOB feeds
- 02Source + receipt timestamps
- 03Point-in-time records
- 04Quality & fee checks
- 05Depth simulation & reports
Strategy & methodology
The research foundation’s model-based entry function requires ten explicit gates, including valid rules and station, complete and fresh books, verified fees, model calibration, supported regime, source freshness, and a valid clock. Any failed gate blocks paper entry.
The separately configured three-city paper workflow checks afternoon checkpoints, a 0.90–0.97 price band, and at least 1.5% conservative edge after recorded fees and depth-weighted price. One entry per city/event and a shared exposure cap limit paper deployment.
Implementation
Python uses requests and websockets for ingestion, Decimal for monetary calculations, and zoneinfo for local-day handling. CSV and JSONL records preserve observations, depth, and research evidence; JSON persists paper state.
weather_research contains timestamp validation, precise METAR parsing, resolution emulation, calibration metrics, and full-depth entry evaluation. PySide6 supplies the Windows desktop interface; PyInstaller packaging is declared in the project.
Results & output
Outputs include timestamped order books, observation records, event metadata, trigger reports, research audits, and paper signal/fill records. The repository also contains screenshots of the local monitoring interface.
The documented research foundation explicitly withholds a trained model because its cited archive had only two incomplete event days. The existence of later collectors and strategy scripts does not establish a calibrated predictive edge.
The three-city runbook covers NYC, Chicago, and Toronto. Collection and simulation features are demonstrated; this portfolio makes no profitability claim.
Technical challenges
Receipt-time filtering prevents future observations from leaking into replay. Strict UTC handling and local timezone conversion preserve the correct event date across day boundaries.
Long recordings produce large full-depth files. Completed books can be losslessly compressed only after verifying the decompressed SHA-256 digest, while research readers support both raw and compressed records.
Takeaways
WeatherBot demonstrates that reliable research starts with the data record. Source interpretation, timestamp discipline, and explicit missing-data states are part of the system’s behavior, not just documentation.