Weather prediction markets: station, observation and time window

Read the settlement clause before the forecast

A weather contract is a claim about a measured value produced by a named measurement system inside a defined time window. Before you look at any forecast, extract 5 fields from the rules: the station (for example Jinan Yaoqiang International Airport Station), the measured quantity (highest recorded temperature), the local day or window, the unit and rounding precision (whole degrees Celsius), and the finalization and revision rule (no revisions after data is finalized count). If any field is missing or maps to more than 1 instrument, the market is not yet readable. The contract text, not the city name in the title, governs.

The resolution documentation states plainly that rules specify source, deadline and edge cases, and that the title alone is insufficient. For ordinary binary prediction outcomes, a winning share pays 1 and a losing share pays 0; a rare unknown or 50-50 resolution can pay .50 each, which is not a universal cancellation or refund. Confirm the specific market's rules rather than importing a default from another venue or another weather product.

Airport station, city app and the gap between them

The NWS Chicago observation FAQ treats airport stations and their observations as distinct from forecasts, and it documents why 2 numbers for the same city can both be correct. Short 5-minute METAR reports use reduced precision, Celsius rounding and conversion back to Fahrenheit can differ from the original station observation, and a daily extreme can occur between disseminated reports. The daily period for those NWS climate products follows local standard time even during daylight saving time; this is source-specific and is not a universal day definition for Wunderground or for every country.

The Jinan rule snapshot illustrates a different, source-specific configuration. It names the Jinan Yaoqiang International Airport Station, points to Wunderground's history page for that station, measures to whole degrees Celsius, and excludes revisions recorded after the data is finalized. Do not substitute the NWS local-standard-time day, or the NWS monthly CF6 preliminary report, for that Wunderground finalization rule. Each market's nominated source and finalization rule govern its own resolution. CLI climate data are preliminary and subject to revision, with final NCEI quality control later; a contract that explicitly uses a different source overrides that default.

Because the contractual statistic is a finalized observation from a nominated source, a phone weather app forecast shown for the same city is not the resolving number. Keep the 2 data sets separate: the app figure is a model output that may be archived before the outcome, and the settlement figure is the record the source publishes after finalization. Archiving the forecast you saw, with its timestamp, lets you later compare your own reading process without pretending that the forecast and the settlement figure are the same quantity.

Worked decision: forecast 29C against a finalized maximum of 28C

The following case is explicitly illustrative. Suppose you read a market whose rules name a specific airport station, measure the highest recorded temperature to whole degrees Celsius, and exclude post-finalization revisions. Your city app shows a forecast of 29C for the day. The nominated source later finalizes that station's maximum at 28C. The forecast and the recorded extreme are separate data products; the contract asks for the second, so the 29C figure never enters settlement. Neither number here is a real observation, and no accuracy rate for any model is implied.

The decision value of this example is procedural, not predictive. It forces you to identify which published figure the rules select, at what precision, and at what point the data stops changing. It does not tell you whether either figure is more likely, and nothing here is a weather signal or a source of expected edge.

Decision table: what each field selects

Use the table as a checklist against the rules text. Each row names a field that resolves ambiguity between 2 otherwise plausible readings, and the last column states what to verify in the market documentation before you treat the contract as readable.

Limits, uncertainty and what to do next

The contract’s own rules specify the source, deadline and exceptional cases. Check those clauses for the question being examined, since a title alone cannot determine settlement.

An archive-before-outcome habit reduces ambiguity: record the forecast you relied on, the timestamp, the source URL and the rules text version. That record cannot confirm a model's accuracy from a single case, and it says nothing about profitability. Its only job is to make your later reconstruction of the decision honest about which statistic governed. When you need the underlying measured value rather than an app display, start with the topic on temperature readings. To see how recorded observations compare with later outcomes, the calibration topic explains scoring and error measures attached to forecast archives. The journal topic covers keeping dated records of what you observed and decided. The resolution topic explains how a source, deadline and edge case become a final payout allocation.