How Poly Weather Analyzer Works
This guide explains the data flow, probability model, confidence score, scenarios, and analytical assumptions behind the project.
Contents
- System Objective
- Data Collection
- Event Parsing
- Location Resolution
- Forecast Normalization
- Uncertainty Estimation
- Temperature Brackets
- Probability Calculation
- Market Probability
- Pricing Edge
- Expected Value
- Confidence Score
- Scenario Analysis
- Sensitivity Analysis
- Important Assumptions
- Future Improvements
System Objective
The system estimates the probability distribution of a target-day temperature and compares that distribution with Polymarket outcome prices.
The central analytical question is:
How does the probability assigned by a weather ensemble differ from the probability implied by the prediction market?
The analyzer does not attempt to prove that either system is always correct. Instead, it quantifies their disagreement.
Data Collection
Polymarket Gamma API
The Gamma API provides:
- Event ID
- Event title
- Event slug
- Description
- Resolution source
- Start and end dates
- Outcome markets
- Yes and No prices
- Liquidity
- Volume
- Bid and ask prices
- Last trade price
- CLOB token IDs
Polymarket CLOB API
The CLOB API provides historical token-price observations when available.
MicroaiBots — Solana & Prediction Market Trading Bots
Explore configurable Solana, Polymarket, Jupiter, and DFlow trading automation tools. Get instant digital delivery, guided installation, risk controls, and priority Telegram support.
microaibots.com
Historical prices help answer:
- Has the market recently moved?
- Which bracket gained probability?
- Did weather updates produce a price reaction?
- Is the current price an outlier relative to recent trading?
Weather APIs
Each weather provider is converted into a common forecast record:
{
"source": "Provider name",
"model": "model_identifier",
"maximum_c": 29.1,
"minimum_c": 23.4,
"low_c": 27.8,
"high_c": 30.4
}
This common structure allows different providers to be combined.
Event Parsing
The analyzer extracts the city from titles such as:
Highest temperature in Shanghai on September 10?
It also reads the event date from:
eventDateendDate- A date embedded in the title
Temperature outcomes are usually identified by groupItemTitle.
Examples:
25°C or below
26°C
27°C
28°C
29°C
30°C
34°C or higher
Location Resolution
The location name is passed to the Open-Meteo geocoding API.
The response includes:
- Canonical location name
- Country
- Administrative region
- Latitude
- Longitude
- Time zone
- Elevation
The time zone is important because daily maximum temperature must be calculated using the target location's calendar day rather than UTC.
Resolution-station warning
The geocoded city center may not match the official market resolution station.
For example, a market may resolve using an airport station outside the city center. Differences can arise from:
- Urban heat effects
- Elevation
- Coastal influence
- Distance from the city center
- Station exposure
- Observation timing
Exact station matching should be preferred whenever station metadata is available.
Forecast Normalization
Different providers return different structures:
| Provider Type | Typical Structure |
|---|---|
| Daily forecast | One daily maximum and minimum |
| Hourly forecast | Hourly temperatures aggregated to a daily maximum |
| Ensemble forecast | Many forecast members for each hour |
| Official forecast | Human-adjusted or national-service forecast periods |
The data layer converts these formats into Celsius.
Hourly forecast values are filtered using the target location's local date. The highest valid hourly temperature becomes the source's daily maximum estimate.
Uncertainty Estimation
Each source needs both a forecast center and an uncertainty estimate.
The project derives a source standard deviation from its lower and upper interval:
A lower bound is applied so that a source cannot become unrealistically certain.
When an interval is unavailable, the configured default is used:
DEFAULT_TEMPERATURE_SIGMA=1.5
Temperature Brackets
Markets resolved to whole degrees need continuous probability boundaries.
Exact whole-degree bracket
For a 29°C outcome:
This method maps a continuous forecast distribution to whole-degree observations.
Normalization makes the modeled outcome set sum to one.
Market Probability
Each temperature outcome is represented by a binary Yes/No market.
The Yes price is interpreted as the raw market-implied probability:
Normalization compensates for small inconsistencies across separate binary books.
It does not eliminate:
- Bid-ask spread
- Fees
- Stale orders
- Thin liquidity
- Execution costs
Pricing Edge
The probability edge is:
Interpretation
| Edge | Meaning |
|---|---|
| (E_i > 0) | Model assigns more probability than the market |
| (E_i \approx 0) | Model and market approximately agree |
| (E_i < 0) | Market assigns more probability than the model |
A positive edge is not automatically a trade recommendation.
The difference may be caused by:
- Model bias
- Incorrect geocoding
- Resolution-station differences
- Unmodeled weather behavior
- Market information not included in the APIs
- Forecast update timing
- Liquidity distortions
Expected Value
The simplified expected-value ratio is:
[
EV_i
\frac{P_{\text{model},i}}
{Price_{\text{Yes},i}}
-1
]
If the model probability is 20% and the Yes price is 10%:
[
EV = \frac{0.20}{0.10}-1 = 1.0
]
The displayed value is +100%.
This calculation does not include execution costs or payout timing. It is best treated as a screening metric rather than a final return estimate.
Confidence Score
The confidence score combines four components.
Source coverage
More independent forecast sources increase coverage.
where (D) is the standard deviation of source maximum-temperature forecasts.
Outcome concentration
A stronger leading probability produces a higher concentration component.
Confidence labels
| Score | Label |
|---|---|
| 80–100 | Very high |
| 65–79.99 | High |
| 50–64.99 | Moderate |
| 35–49.99 | Low |
| Below 35 | Very low |
The score measures internal model conditions. It is not a historical accuracy guarantee.
Scenario Analysis
The analyzer creates three scenarios:
| Scenario | Temperature | Weight |
|---|---|---|
| Cool | Ensemble mean minus ensemble uncertainty | 20% |
| Base | Ensemble mean | 60% |
| Hot | Ensemble mean plus ensemble uncertainty | 20% |
Each scenario is mapped to its corresponding market bracket.
Scenario analysis provides an intuitive view of which outcome wins if the forecast shifts colder or warmer.
Sensitivity Analysis
A prediction can appear strong only because of a specific uncertainty assumption.
The sensitivity model varies:
- Forecast bias from approximately
-3°Cto+3°C - Standard deviation from approximately
0.5°Cto4°C
For each pair of assumptions, it recalculates the selected outcome's probability edge.
Reading the sensitivity chart
| Pattern | Interpretation |
|---|---|
| Large stable positive region | Edge survives many assumptions |
| Narrow positive region | Edge is fragile |
| Rapid sign changes | Small forecast changes alter the conclusion |
| Mostly negative region | Market generally assigns more probability |
| Strong uncertainty dependence | Distribution width drives the result |
The sensitivity chart is one of the most important safeguards against overconfidence.
Important Assumptions
Normality
Source temperature uncertainty is approximated with a normal distribution. Real forecast errors may be:
- Skewed
- Heavy-tailed
- Regime dependent
- Seasonally biased
- Location dependent
Source independence
Several providers may rely on the same underlying numerical models. Averaging providers does not necessarily create independent evidence.
Equal weighting
The mixture currently gives comparable influence to available normalized forecast sources. A calibrated system should weight sources using historical performance.
Stable uncertainty
Source uncertainty is estimated from intervals or defaults. True uncertainty changes with:
- Forecast horizon
- Weather regime
- Geography
- Season
- Model initialization
- Observation station
Resolution precision
Half-degree boundaries assume whole-degree rounding. The actual resolution procedure must be confirmed from the event rules.
MicroaiBots — Solana & Prediction Market Trading Bots
Explore configurable Solana, Polymarket, Jupiter, and DFlow trading automation tools. Get instant digital delivery, guided installation, risk controls, and priority Telegram support.
microaibots.com
Future Improvements
A stronger production model could add:
- Exact station coordinates
- Station elevation correction
- Historical source-bias calibration
- Forecast-horizon-dependent uncertainty
- Model-family deduplication
- Bayesian source weighting
- Heavy-tailed forecast distributions
- Time-series forecast revisions
- Proper scoring-rule backtesting
- Market fee and spread modeling
- Order-book execution simulation
- Automated station observation tracking
The current system is designed as a transparent research framework. Its modular structure makes each assumption replaceable.
Top comments (0)