How to write clear weather market questions

Before you start: what a clear weather market question does

In simple terms, a weather market question defines a single measurable event that will be checked against an objective data source at settlement. The goal is to make it obvious whether the outcome is Yes or No.

Ambiguity causes disputes and delays: it lowers confidence in prices, increases moderator workload, and slows settlement. Before drafting, keep in mind the single-goal rule: pick one place, one time window, one measurement method, and one dataset, and lock those choices into the text.

Step-by-step drafting: the exact pieces to include

Follow this numbered checklist when you write a weather market question. Under each step: what you will see in the draft and what can go wrong if you skip details.

1. Choose the exact observation point.

   • What you see: an official station name and identifier, for example "KBUF — Buffalo Niagara International Airport" or another station code.
   • What can go wrong: saying only a city name ("New York") leaves open whether you mean Central Park, JFK, LaGuardia, or Newark, and invites dispute.

2. Define the time window with precise endpoints and time zone.

   • What you see: explicit start and end times and dates such as "00:00–23:59 local time on 2026-09-01" or UTC equivalents.
   • What can go wrong: words like "tomorrow" or "this week" create timezone and endpoint disputes; omitting time zone creates ambiguity about which calendar day is intended.

3. Specify the measurement and units, including rounding.

   • What you see: the metric being measured and its units, e.g., "daily maximum temperature in degrees Fahrenheit, rounded to the nearest 0.1°F" or "total liquid precipitation in millimeters, 24-hour accumulation."
   • What can go wrong: not stating rounding rules leads to disputes over borderline values (for example, 0.049 in may round to 0.0 or 0.05 depending on the rounding rule). Also clarify whether precipitation is liquid-equivalent.

4. Name the primary settlement source and a single clear fallback.

   • What you see: the dataset and provider, such as "NOAA Integrated Surface Database (ISD) daily summary for station 727930-24231," plus a single fallback like "If ISD is unavailable, use the NWS official daily summary for KSEA."
   • What can go wrong: saying only "official NWS" without dataset/table forces resolvers to pick arbitrarily. Multiple fallback options or vague fallbacks create extra moderator work.

5. State how to interpret thresholds and inequalities.

   • What you see: explicit threshold language, e.g., "at least 75°F (>= 75.0°F)" or "greater than 0.00 in (>)", and whether endpoint values are inclusive.
   • What can go wrong: unclear threshold logic lets parties argue over whether a boundary value qualifies. Use >= or > language in plain English to avoid confusion.

Follow that order when you draft a question: station, window, measurement, units/rounding, data source, fallback, threshold logic.

What it looks like when a question is clear and how settlement works

A clear question makes the settlement step straightforward: the resolver reads the specified dataset for the named station and applies the stated rounding and threshold rules.

A simple example of a settled trade: Suppose a Yes contract — an event contract that pays $1 if the event happens — costs 62¢ for the question, "Will the daily maximum temperature at KSEA (Seattle–Tacoma International Airport) reach at least 75.0°F on 2026-08-01, local date? Primary source: NOAA Integrated Surface Database (ISD) daily summary for station 727930-24231. If ISD is unavailable, use the NWS official daily summary for KSEA. Rounding: maximum observed temperature rounded to nearest 0.1°F."

Buying one Yes contract costs $0.62. If the NOAA record shows a maximum of 76.3°F on that date, the contract pays $1, so the gain before fees is $0.38. If the maximum is 74.9°F, the contract expires at $0, so the loss is $0.62.

What you see at resolution: a single data value from the named source and one clear application of rounding and inequality rules. What can go wrong at this stage is usually a missing dataset file or an unexpected station code change — which is why the fallback rule exists.

Where people get stuck and how to avoid it

• Missing the station identifier

  • Problem: Listing only a city name ("New York") leaves open multiple stations.
  • Fix: Always include station name and, if available, its code.

• Vague time window

  • Problem: Relative phrases ("tomorrow") and unspecified timezones cause interpretation disputes.
  • Fix: Use calendar dates and exact hours, and specify timezone or UTC.

• Not stating rounding or measurement conventions

  • Problem: A value like "0.049 in" can be rounded differently unless rules are given.
  • Fix: Specify rounding precision (nearest 0.1°F, nearest 0.01 in, etc.) and whether precipitation is liquid-equivalent.

• No clear fallback source

  • Problem: "Official NWS" without naming dataset forces ad-hoc resolver choices.
  • Fix: Name the primary dataset and give one unambiguous fallback with a single condition that triggers it.

If you address each point in the drafting checklist in order, you avoid the common sources of dispute and cut moderator overhead.

Related reading

• What Are Prediction Markets?
• What Are Yes/No Contracts?
• How to Read Prediction Market Prices
• How Prediction Market Payouts Work