Save Resolution Rule Provenance With Your Market Data

If you backtest prediction-market strategies, you probably store prices, volumes and outcomes. The thing most datasets drop is the resolution rule as it existed while the market was live. That omission quietly corrupts any backtest that touches ambiguous or source-dependent markets, because the question a contract settles is not the headline on the market tile.

On Kalshi, the binding text is the contract terms document the exchange writes and files with the CFTC, and that document, not the card summary, decides whether you get paid. Treat the rule itself as a first-class, versioned column in your dataset.

Why the rule text is data, not metadata

A Kalshi market has written terms that define the event, the measurement method, an observation window or deadline, and a named resolution source. Settlement runs on those documented criteria as interpreted by the exchange, not on a subjective judgment about what should have happened. If your dataset only keeps the one-line summary, you have thrown away the layer that actually governs the payout.

The gap bites hardest where the source is non-obvious. Kalshi weather markets name an official settlement source in each market's rules, and that source is not a generic app reading. Daily temperature historically settled on the National Weather Service daily climate report for a named station, and a backtest of those markets is only reproducible if you recorded which station and which product the rule pointed at.

A rule changed under live markets: a concrete case

Provenance is not academic. Kalshi changed the resolution source for its daily temperature markets starting August 14, 2026. Under a data partnership announced August 28, 2026, those contracts now settle against data from The Weather Company rather than the National Weather Service. One confusing detail: the station is still identified by its NWS-style climate report product ID, like CLINYC, while the reporting authority changed.

Kalshi's rulebook (Rule 7.2, Contract Modifications, filed publicly with the CFTC) reserves exactly this power. Rule 7.2 states that when any event may have a material impact on the reliability or transparency of a contract's Source Agency, Kalshi retains the authority to designate a new Source Agency and to change any associated contract specifications after the first day of trading. So a market you backtest across that August 14 boundary has two different settlement rules depending on the date. If your rows all carry the latest rule text, your pre-August backtest is settling against a source that did not govern those historical contracts.

The historical version is not what you learned after settlement

Keep two timelines separate. The first is the rule as published and effective while the market traded, captured at a known time. The second is everything you learned afterward: the final result, a later clarification, a source swap, a review-committee determination. Mixing them is a form of lookahead that no amount of clean price data will fix.

Kalshi's own lifecycle reflects this. After close, determination is the exchange grading the contract against its named source. Kalshi's documentation notes determination can take anywhere from one hour to more than 12 hours, because the exchange waits on the official record rather than the broadcast. Where an outcome is ambiguous, the rulebook provides for a review process and for Rule 6.3(c), under which Kalshi may use the last traded price when a contract expires without a clearly determinable outcome. None of that is knowable at trade time, so none of it belongs in the rule version your live-time strategy would have read.

What to store per market version

Capture a new versioned record whenever the terms, source or specifications change. At minimum:

• Full rule text, verbatim, not a paraphrase or summary. The summary persuades; the contract terms govern.
• Named settlement source and any fallback hierarchy, including the exact identifier (for example a station or product code) and the provider, since those can diverge.
• Cutoff and observation window: the measurement time, time zone, and any tie-handling clause. Some Kalshi contracts resolve YES on an exact tie because the terms read 'is at least' the reference.
• Capture time (UTC) and where you fetched it, so you can distinguish the rule you saw from a later amendment.
• Later clarifications and amendments as separate, timestamped records, never overwriting the earlier version.
• A fallback-data clause when present. Some Kalshi contract terms resolve off the most recently available published data if the source is missing at the settlement time, rather than voiding.

Preserve unknowns explicitly. If a rule is silent on an edge case, record that it is silent rather than filling it with your own guess. 'Unknown' is a legitimate, queryable value; a fabricated rule is not.

Where this fits with paper research

Banger (bangertrades.com) is a paper-research beta for prediction-market strategy builders, where you write a Python strategy or clone a marketplace one, inspect versioned historical backtests and run bounded paper experiments. Its hosted historical backtesting currently supports Kalshi binary markets. The discipline here is the same one Banger assumes: a paper result is evidence under a particular data, fill, fee and valuation model, not proof of profitable real execution. A rule-version mismatch poisons that evidence before the fill model ever runs, so pin the historical rule to each market and keep the post-settlement knowledge in a separate lane.

Public market observations do not require venue trading keys, so you can build and verify this provenance layer against public contract terms and the Kalshi API without funding an account. When you verify, read the primary contract terms for the exact ticker and date you are testing, record what you read and when, and treat any precise settlement detail as true only as of its capture time. Rules here move; your dataset should remember which rule was live.