PolyWeather Lab

Overview

PolyWeather Lab asks whether published observations can invalidate temperature brackets before market quotes adjust. It links an observation’s evidence to a signal, a delayed paper order, a fill, and eventual settlement in an auditable ledger.

Problem

An observation is not automatically final settlement evidence. Source revisions, incomplete day coverage, contractual rounding, and the time required to reach an order book can invalidate an apparent advantage.

Approach

Require manual contract approval, keep observation vintages, and separate public evidence from synthetic demonstration data. The forward simulator and historical replay share the same execution engine, while replay uses an isolated ledger.

How it works

Gamma metadata feeds versioned contract rules. NWS and Aviation Weather Center adapters supply receipt-stamped observations; CLOB REST and WebSocket adapters reconstruct market depth.

After quality checks, the engine reserves paper cash and schedules arrival. At arrival it walks the available ask ladder with the configured depth haircut, fees, and slippage. Fills and settlements retain references to the input evidence.

1. 01Approved contract rules
2. 02Receipt-stamped observations
3. 03Signal & reservation
4. 04Arrival-time book walk
5. 05Fill, settlement & replay

Strategy & methodology

Observation elimination considers NO shares in brackets already exceeded by an accepted observation, allowing for correction risk. Finalization requires explicit complete-day coverage and revision/finality evidence; midnight alone is insufficient.

Replay excludes retrospective observations without verified receipt provenance and applies same-timestamp book updates before arriving orders. Forward parameters lock before scanning. Assumed signal probabilities and depth haircuts are configuration choices, not empirical calibration.

Implementation

FastAPI exposes research operations. Pure domain calculations use Decimal; a network-independent engine owns gating, reservations, delayed fills, and settlement. SQLAlchemy and Alembic provide the evidence/lifecycle schema with local SQLite storage.

The Next.js/React interface uses Recharts and refreshes from a WebSocket with REST fallback. Docker Compose describes an optional PostgreSQL deployment, but the documentation identifies that runtime as locally unverified.

Results & output

The public audit retained six contract records and 18 snapshots, including six empty disconnect markers. The 12 populated books were all one-sided; there were no public signals or fills. This is evidence of connectivity, not executable arbitrage.

An offline synthetic check produces +$5.547709 at a one-second arrival delay, no fill at three seconds, and −$199.999999 after a post-fill correction. These prescribed scenarios exercise timing and accounting; they are not estimated market returns.

Public audit: 6 September 2026, with a roughly two-second populated-book capture. All 12 populated books were one-sided; connectivity is demonstrated, executable edge is not.

Technical challenges

Availability time differs from observation time. The replay clock activates evidence only once it could have been received and parsed, while conservative tie ordering avoids filling against a cheaper book that has already changed.

Versioned rules and correction vintages preserve the reasoning behind a decision. Database transactions keep reservations and cash consistent, but the deployment deliberately uses one worker rather than claiming distributed execution safety.

Takeaways

The project demonstrates an execution model that can explain why a trade happened, why it was rejected, and what a correction changes. Its public sample is too short to support a repeatable market-edge claim.