Symbology Explorer
A working view of the canonical entity, event, and outcome registry behind Oddpool — the reference data layer that maps every Kalshi market and Polymarket condition to a single Oddpool ID. Use the explorer at the top to walk through real cross-venue pairs interactively. The blocks below highlight specific patterns the schema catches — the cases that make a flat “event mapping table” not enough.
Loading...
Patterns the schema catches
Each card below is one specific failure mode of a naive event-pairing approach, and how the symbology handles it.
Surface-form drift collapses to one entity
Three different strings across venues, one canonical Oddpool ID. The alias array preserves the original surface forms for round-trip lookup.
Outcome labels parsed into structured fields, not strings
A "Lula da Silva, 0–5%" outcome decomposes into entity_opid + bucket. The schema knows the semantic shape; downstream consumers don't have to parse strings.
Cumulative ≠ discrete, even for the same election
Kalshi's "Mejia ≥30%" resolves YES at any margin above 30%. Polymarket's "Mejia 30–35%" resolves YES only inside that range. Same election, NOT settlement-fungible per outcome.
Same outcome, different deadlines
The same House race resolves three months apart on the two venues. Polymarket settles on election day; Kalshi settles when the new Congress is sworn in. A position open at year-end is hedged on one venue and unsettled on the other.
Most cross-venue pairs aren't truly fungible
On a sample of 250 matched events, only about a third are basis_class=identical. The rest carry a real settlement difference, recorded explicitly so it isn't mistaken for a clean spread.
Polymarket placeholders never enter the registry
Polymarket lists hidden-name candidates as "Person A", "Show C", "Player K" until they're announced. We detect and skip these so the entity registry stays clean of meaningless OPIDs.