Current definition resdb-v2. Charts stamped with it were computed by src/resolution/schema.py, and every value plotted for a past date could have been computed on that date.
markets one row per contract, both venues, with full rules text resolutions what was proposed, whether it was disputed, what settled links kalshi_ticker <-> polymarket_id, with confidence and method flags where a linked pair's rules diverge, typed and scored
What the venues actually give us, measured (see PHASE4_RESULT.md):
Kalshi rules text on 100% of markets; settlement sources with URLs on
1,457 of 1,459 series. Structured, and the best half of the pair.
Polymarket `resolutionSource` populated on 705 of 4,200 (17%); criteria
otherwise buried in free prose, median 738 characters.
UMA `umaResolutionStatuses` carries the proposal/dispute sequence
directly from Gamma — no Polygon RPC and no Dune. BUILD_PLAN
budgeted a chain-indexing pipeline for this.Newest first. Each entry says what changed and whether values that had already been published moved with it, followed by the sentence from the module that decided the verdict.
settlement_time added — when a contract ACTUALLY settled, which on Kalshi is not expiry_time. See below.
The module does not say whether values already published moved. We would rather show this gap than close it with a guess.
markets + resolutions + candidate links + single-venue flags.
The first version of this metric. There is no earlier definition to restate.
3 charts name this metric in their readout line. None of them names it first, so a count taken from the leading stamp alone reports 0 rather than 3. A chart built on several definitions carries all of them, and being second in that list is not the same as being unused.