Forecasting Polymarket US Weather Markets: Ensemble Models, Resolution Auditing, and Why There's No Instant Backtest

What it actually takes to price a Polymarket US "highest temperature in [city] on [date]" market well: blending forecast sources correctly, verifying what the market actually settles against, and being honest about a real limitation of this specific venue instead of quietly working around it.

Polymarket US is a separate, CFTC-regulated venue from the offshore Polymarket most people have heard of — different company, different legal status, different resolution sources. Five cities currently list daily-temperature markets there: New York, Chicago, Miami, Los Angeles, and San Francisco. Underneath "pick the bucket the high will land in," three separate problems have to be solved before a probability is worth anything: turning several disagreeing forecast sources into one honest distribution, verifying what station and source the market actually resolves against, and being straight about what can and can't be proven about the result.

Blending forecasts without just averaging them

A single forecast model gives you a point estimate with false precision. The fix isn't picking the "best" model, it's building a mixture: ensemble members (dozens of perturbed runs of the same model, which naturally express uncertainty as spread), deterministic multi-model forecasts (several independent models' single best guess), and climatology (what actually happened on this calendar day historically, at this station). Each source gets its own kernel width and its own weight, outliers get downweighted rather than trusted at face value, and the whole mixture's uncertainty grows with how many days out you're forecasting. A 6-day-out forecast should be a wider, less confident distribution than a same-day one, and the model needs to know that explicitly rather than accidentally being overconfident at every horizon.

What a Polymarket US market actually resolves against

Every daily-temperature market on Polymarket US settles against the National Weather Service's Climatological Report (Daily) — the NWS CLI product — at a specific named station, stated right in each bucket's own market description. The stations aren't always the ones a casual guess would land on: New York resolves against KNYC (Central Park), not the airport codes (KLGA/KJFK) a lot of weather data defaults to; Chicago resolves against KMDW (Midway), not KORD (O'Hare). A model that predicts "the temperature in New York" without pinning down which specific station is modeling the wrong target — the right approach parses each bucket's own description, confirms every bucket in the event agrees on the same station, and refuses to price anything it can't verify. Fails closed, not "probably fine."

Why there's no instant backtest for this venue

Score a model with a proper multiclass Brier score (the sum of squared errors between your predicted probabilities and the actual outcome, across every bucket) and the fastest way to get a number is to replay a bulk archive of markets that have already resolved. Some prediction-market venues expose exactly that kind of archive. Polymarket US does not — its public gateway lets you look up a specific market you already know the slug for, and see what's live right now, but there's no "give me every closed weather market from the last 90 days" endpoint to replay.

That's not a minor inconvenience to route around quietly. It means the only honest way to build a real, venue-specific track record is slower: log the model's live probability distribution on real trading days, then once those markets' target dates pass, check whether each one resolved and score it. The Brier score that produces is genuinely earned against this exact venue — it just takes real days to accumulate, and there's no shortcut version of it.

What the live output actually looks like

This is real, unedited output from the engine described here, run against a live Polymarket US market on July 17, 2026, mid-evening New York time:

$ stormedge price

NYC — 2026-07-17 (max, local hour 21.2, obs_extreme=30.0°C,
                  remaining_potential=0.20, confidence=high)

  bucket           model p    market yes
  82°F or below      0.804        ≤0.010
  83-84°F            0.027        ≤0.010
  85-86°F            0.047        ≥0.900
  87-88°F            0.081        ≤0.010
  89-90°F            0.037        ≤0.010
  91°F or higher     0.003        ≤0.010

Notice the "≤" and "≥" symbols instead of a clean number for most buckets — that's real, not a formatting choice. Polymarket US's public order-book data frequently has only one side quoted on a given bucket (a resting ask with no matching bid, or vice versa), especially away from the market's favored outcome. A tool that silently collapses that down to a blank dash is hiding real information; showing the one-sided quote as a bound is the honest version of "here's what we actually know about the market's price right now."

Why the intraday constraint isn't just "if it's late in the day, be more confident"

The naive version of this idea (collapse confidence as the day goes on) breaks in a specific, findable way: your live observation feed is itself an approximation. Hourly-cadence observations miss true peaks and troughs that happen between reports, and auditing real resolved markets against their actual settlement value shows the miss is directional (the true extreme is consistently more extreme than what an hourly feed showed, never less). The fix is a hard floor on how much confidence any time-of-day reasoning is allowed to claim, calibrated to that measured miss rate, not tightened further than the sample size actually supports.

Frequently asked questions

Education and research content. Not financial advice. Prediction markets involve substantial risk of loss.