Event Taxonomy for Prediction Markets: A Developer's Model
Event Taxonomy for Prediction Markets: A Developer's Model
Event Taxonomy for Prediction Markets: A Developer's Model
How to structure an event taxonomy for prediction markets: series, events, markets, outcomes, categories and canonical IDs across Polymarket, Kalshi and Limitless.
Event Taxonomy for Prediction Markets: A Developer’s Model
An event taxonomy for prediction markets is a layered classification that separates a recurring series, a single event, the tradable markets inside it, and the outcomes each market prices. Venues each model these layers differently, so any cross-venue pipeline needs its own canonical taxonomy on top. This guide gives you a working model, the failure modes it prevents, and a mapping approach you can implement.
Assymetrixdata.assymetrix.comBuild on Unified Market DataAssymetrix brings prediction market data from Polymarket, Kalshi, and Limitless together through one API integration.Explore the Data API
TL;DR
Use four core layers: series (a recurring template), event (one instance), market (one tradable question), outcome (one side of that question).
Polymarket and Kalshi both group markets under events, but they name and scope the layers differently. Do not join on titles.
Keep category, resolution type, time horizon and settlement source as separate fields, not one tag string.
Assign canonical IDs at ingestion and store the venue-native IDs beside them, so a remap never rewrites history.
Version the taxonomy itself. A reclassification should be a new record, not an edit.
Table of Contents
Why a taxonomy comes before the analysis
The four structural layers
How venues name the layers
Descriptive axes: keep them separate
Canonical IDs: the part that makes it usable
Matching events across venues
Failure modes the taxonomy prevents
Taxonomy for agents and bots
Versioning the taxonomy itself
Our perspective
Using this with the Assymetrix Data API
Implementation checklist
Sources
Why a taxonomy comes before the analysis
Most cross-venue bugs are classification bugs. A spread calculation that pairs a “Fed decision in December” market with a “Fed rate at year end” market looks like an arbitrage signal until you read the resolution rules. A volume leaderboard that sums markets and events together double counts. A backtest that filters on a free-text category quietly drops half the sample when a venue renames a tag.
A taxonomy is the schema that makes those mistakes impossible to express. It decides what counts as the same thing, what counts as a sibling, and what counts as a different question that merely sounds similar. If you build trading bots, research datasets or agent tools, this is the layer every later query depends on.
The model below is deliberately small. Nine axes are tracked in our longer taxonomy reference for developers, but four structural layers and a handful of descriptive fields cover most production needs.
The four structural layers
Series: the recurring template
A series is a template for events that repeat under the same format and rules. Kalshi documents it exactly this way: its series endpoint describes a series as a template for recurring events, with examples such as a monthly jobs report or weekly jobless claims.
Series matter because they are the unit of strategy. A bot that trades “monthly CPI” markets wants the whole family, across every month, with comparable rules. If your schema has no series layer, you rebuild that grouping with string matching on titles, and it breaks the first time a venue rewords a question.
Not every venue exposes a series object. Where it is absent, you infer one: same settlement source, same cadence, same question template. Store the inferred series with a flag that says it was derived, not supplied.
Event: one instance of something happening
An event is a specific occurrence: one game, one month’s rate decision, one election. It is the natural parent for a set of related markets. Polymarket’s catalog follows this pattern. A Gamma API walkthrough describes an event as a group of one or more markets that share a question theme, with fields for slug, title, end date, active and closed flags, volume and tags.
Two practical points follow from that:
The event’s end date is not necessarily each market’s resolution time. Treat them as separate timestamps.
An event can contain mutually exclusive markets (who wins) or independent ones (several thresholds). Record which, because it changes how probabilities should sum.
Market: one tradable question
A market is a single question with its own order book. On Polymarket, per the same walkthrough, a market is a specific Yes/No outcome with its own order book and token IDs. On Kalshi, the tiers run series, event, then market ticker, and the market is the contract you actually trade.
The market is where price, liquidity, spread and volume live. It is also where resolution rules attach. Two markets with near-identical titles and different rules are different markets, full stop.
Outcome: one side of the question
Outcomes are the priced sides of a market. Binary markets have two. Categorical events are usually modeled as several binary markets under one event. Scalar and bucketed designs add a further wrinkle: each bucket is its own market, yet the buckets form a distribution.
Keep the outcome as its own row. It gives you a stable place to hang a token ID, a label, a last price and a resolved value, and it lets a single query handle binary and multi-outcome designs alike.
How venues name the layers
The same concept appears under different labels. A mapping table is the first artifact worth writing down.
Canonical layer | Polymarket | Kalshi | What to store |
|---|---|---|---|
Series | Not a first-class object in the catalog | Series (ticker) | Native ID, or a derived series key with a derived flag |
Event | Event (slug) | Event (ticker) | Native ID, title, start and end times, mutual-exclusivity flag |
Market | Market (with token IDs) | Market (ticker) | Native ID, question text, rules text, status |
Outcome | Outcome token | Yes/No side | Label, token or side ID, last price, resolved value |
Treat the Limitless column as something you fill from its own documentation during integration. Do not assume it matches either of the other two. Our venue landscape overview covers how the platforms differ in structure and regulatory posture.
Descriptive axes: keep them separate
Structure tells you what contains what. Descriptive fields tell you what a market is about and how it behaves. The common mistake is collapsing them into one tag array.
Category and subcategory
Venues ship their own tag systems. Polymarket’s tags carry numeric IDs, with top-level tags such as Sports, Politics and Crypto, and narrower ones such as NBA or Election, as the Gamma walkthrough lists. Those tags are venue vocabulary. Map them into your own two-level category tree, and store the original tags unchanged next to it.
Why two levels? Because analysts ask both “all sports” and “all NBA totals.” A flat list forces either too many categories or too little resolution. Note that crypto here means a market’s subject matter, such as a price threshold question, and is a category like any other, not a topic of this guide.
Resolution type
Record how the question is decided:
Data release (a statistical agency publishes a number)
Official result (an election authority, a league)
Price reference (an index or exchange print at a given time)
Discretionary (a committee or oracle process decides)
Resolution type predicts dispute risk, timing and the shape of the information flow before settlement. It is one of the best features for grouping markets in a model.
Time horizon
Store at least three timestamps: market open, last trading time, and expected resolution. Derive a horizon bucket (intraday, days, weeks, months, long-dated) from them rather than hand-labeling. Several “edges” documented in the research literature, such as longshot effects, behave differently by horizon, so this field earns its place.
Settlement source
Name the authority the market defers to: a specific agency release, a named sports data provider, a certified result. Two markets with the same settlement source and the same threshold are candidates for a cross-venue pair. Two with different sources are not, however similar the titles.
Structure type
Flag binary, categorical (mutually exclusive set), threshold ladder, bucketed scalar, or combinatorial. This is the field that tells your code whether to normalize probabilities across siblings.
Canonical IDs: the part that makes it usable
A taxonomy without stable identifiers is a diagram. The practical recipe has four rules.
Mint a canonical ID per layer at ingestion. One for the series, event, market and outcome. Never reuse them.
Keep the native IDs as attributes. The Polymarket slug and token IDs, the Kalshi tickers, stored verbatim.
Make matches explicit records. A cross-venue match between two markets is a row with a method, a confidence and a timestamp, not an implicit join.
Never edit, only supersede. If a market is reclassified, write a new version and close the old one. Backtests then reproduce what you knew at the time.
The approach is the same one we describe in our guide to canonical IDs for cross-venue data, and our metadata schema guide lists the fields we would keep on each record.
A minimal record
{ "canonical_market_id": "mkt_01H...", "canonical_event_id": "evt_01H...", "canonical_series_id": "ser_01H...", "series_derived": false, "venue": "kalshi", "native_ids": { "market_ticker": "...", "event_ticker": "...", "series_ticker": "..." }, "category": ["economics", "inflation"], "venue_tags": ["..."], "structure_type": "threshold_ladder", "resolution_type": "data_release", "settlement_source": "...", "opens_at": "...", "closes_at": "...", "resolves_at": "...", "taxonomy_version": 3 }
{ "canonical_market_id": "mkt_01H...", "canonical_event_id": "evt_01H...", "canonical_series_id": "ser_01H...", "series_derived": false, "venue": "kalshi", "native_ids": { "market_ticker": "...", "event_ticker": "...", "series_ticker": "..." }, "category": ["economics", "inflation"], "venue_tags": ["..."], "structure_type": "threshold_ladder", "resolution_type": "data_release", "settlement_source": "...", "opens_at": "...", "closes_at": "...", "resolves_at": "...", "taxonomy_version": 3 }
The field names are illustrative. The principle is that every layer has an ID, every venue-native value is preserved, and the version is part of the row.
Matching events across venues
Once each venue is mapped, the next question is which markets are the same question. A defensible matching pipeline runs in stages:
Filter by category and structure type. Only compare like with like.
Filter by settlement source and resolution window. Different authority or different date means no match.
Compare thresholds and wording. Normalize units, dates and direction (above or below).
Score and label. Record an exact, near or related label with a confidence, and keep related matches out of any price-gap calculation.
Review the edge cases. Sample the borderline pairs by hand before trusting the rest.
Only the exact tier should feed spread or arbitrage work. Our measurement guide to cross-venue price gaps covers what to do after a pair is confirmed, including why quoted gaps and executable gaps differ.
Failure modes the taxonomy prevents
Double counting. Summing event volume and market volume in one total. Fix: separate layers, aggregate at one layer only.
Phantom arbitrage. Pairing markets with different settlement sources or cutoffs. Fix: match on source and window before price.
Silent category drift. A venue edits a tag and a filter loses rows. Fix: keep native tags, filter on your own tree.
Broken series history. A title changes, and last month’s market no longer joins this month’s. Fix: series IDs independent of text.
Unreproducible backtests. A reclassification rewrites the past. Fix: versioned records. See our note on reproducible workflows across datasets.
Taxonomy for agents and bots
An agent reasoning over markets needs the taxonomy even more than a human does, because it cannot glance at a page and infer that two questions differ. Give it structured fields: structure type, resolution type, settlement source, horizon. Prompts that rely on titles alone invite confident mistakes.
For tool design, expose the layers as separate calls: list series, list events in a series, list markets in an event, fetch outcomes. That keeps responses small and lets the agent walk the hierarchy the way an analyst would. Event categories are also what let an agent specialize. Work on AI agents predicting sports event results shows why a clean event listing is the first input such a system needs. Our agent data guide goes into response shaping.
For bots, the series layer is the unit of deployment. You write a strategy for “weekly jobless claims” once and let it pick up each new event automatically. On Kalshi that flow is series, then events, then markets. Bots that hard-code individual market tickers need manual upkeep every cycle.
Versioning the taxonomy itself
Your category tree will change. A new venue launches, a topic becomes large enough to deserve its own branch, a mapping turns out wrong. Plan for it:
Give the taxonomy a version number and stamp it on every classified record.
Keep a mapping table from venue tags to your categories, with effective dates.
When you remap, write new rows rather than updating, and keep both versions queryable.
Publish a short changelog internally. Researchers will ask why a number moved.
Our perspective
Most teams treat classification as a cleanup step. We treat it as infrastructure. When we normalize Polymarket, Kalshi and Limitless into one schema, the taxonomy is what lets a Smart Money wallet’s activity, a Trader Skill Score and a cross-venue price gap all refer to the same underlying question.
Our position is that a venue-neutral taxonomy has to sit outside any single exchange. A venue’s own tags serve that venue’s interface. A research or trading pipeline needs identifiers and categories that stay stable when a venue renames something, and that preserve the native fields so nothing is lost.
That is why we pair canonical IDs with the original venue identifiers, and why we build on a large historical record rather than only live data. A taxonomy you cannot apply to history is a taxonomy you cannot test.
Dean
Using this with the Assymetrix Data API
If you would rather not maintain the mapping layer yourself, our Data API gives developers, quants and agents unified access to cross-venue prediction market data through a single integration, built on roughly 1.5 terabytes of history. Canonical IDs and normalized market schemas are part of what it provides. Details are on the Data API page, and the real-time and historical feed guide walks through the endpoints.
The API has free and paid tiers. For current plans and access terms, see the Assymetrix site.
Implementation checklist
Define the four layers and write the mapping table for each venue.
Choose your category tree, two levels deep, and map venue tags into it.
Add resolution type, settlement source, structure type and three timestamps.
Mint canonical IDs and keep native IDs verbatim.
Build matching as explicit, scored, versioned records.
Restrict price-gap and arbitrage logic to exact matches.
Stamp every record with a taxonomy version.
Test against history before going live.
FAQ
What is an event taxonomy in prediction markets?
It is the classification scheme that organizes listings into layers: series, events, markets and outcomes, plus descriptive fields such as category and resolution type. It lets you compare, group and join markets reliably. Each venue has its own version, so cross-venue work needs a shared one.
What is the difference between an event and a market?
An event is a specific occurrence, such as one game or one rate decision. A market is a single tradable question about it, with its own order book. One event can hold many markets, which is how Polymarket’s catalog describes the relationship.
Do all venues have a series layer?
No. Kalshi documents series as templates for recurring events. Where a venue does not expose one, you can derive it from cadence, wording template and settlement source. Mark derived series so they can be audited.
Should I use venue tags as my categories?
Keep them, but do not rely on them alone. Store the original tags unchanged and map them into your own category tree. That way a venue renaming a tag does not change your filters or your backtests.
How do I match the same event across venues?
Compare category, structure type, settlement source, resolution window and threshold before any text similarity. Label matches exact, near or related, and use only exact matches for price-gap analysis.
Sources
Event Taxonomy for Prediction Markets: A Developer’s Model
An event taxonomy for prediction markets is a layered classification that separates a recurring series, a single event, the tradable markets inside it, and the outcomes each market prices. Venues each model these layers differently, so any cross-venue pipeline needs its own canonical taxonomy on top. This guide gives you a working model, the failure modes it prevents, and a mapping approach you can implement.
Assymetrixdata.assymetrix.comBuild on Unified Market DataAssymetrix brings prediction market data from Polymarket, Kalshi, and Limitless together through one API integration.Explore the Data API
TL;DR
Use four core layers: series (a recurring template), event (one instance), market (one tradable question), outcome (one side of that question).
Polymarket and Kalshi both group markets under events, but they name and scope the layers differently. Do not join on titles.
Keep category, resolution type, time horizon and settlement source as separate fields, not one tag string.
Assign canonical IDs at ingestion and store the venue-native IDs beside them, so a remap never rewrites history.
Version the taxonomy itself. A reclassification should be a new record, not an edit.
Table of Contents
Why a taxonomy comes before the analysis
The four structural layers
How venues name the layers
Descriptive axes: keep them separate
Canonical IDs: the part that makes it usable
Matching events across venues
Failure modes the taxonomy prevents
Taxonomy for agents and bots
Versioning the taxonomy itself
Our perspective
Using this with the Assymetrix Data API
Implementation checklist
Sources
Why a taxonomy comes before the analysis
Most cross-venue bugs are classification bugs. A spread calculation that pairs a “Fed decision in December” market with a “Fed rate at year end” market looks like an arbitrage signal until you read the resolution rules. A volume leaderboard that sums markets and events together double counts. A backtest that filters on a free-text category quietly drops half the sample when a venue renames a tag.
A taxonomy is the schema that makes those mistakes impossible to express. It decides what counts as the same thing, what counts as a sibling, and what counts as a different question that merely sounds similar. If you build trading bots, research datasets or agent tools, this is the layer every later query depends on.
The model below is deliberately small. Nine axes are tracked in our longer taxonomy reference for developers, but four structural layers and a handful of descriptive fields cover most production needs.
The four structural layers
Series: the recurring template
A series is a template for events that repeat under the same format and rules. Kalshi documents it exactly this way: its series endpoint describes a series as a template for recurring events, with examples such as a monthly jobs report or weekly jobless claims.
Series matter because they are the unit of strategy. A bot that trades “monthly CPI” markets wants the whole family, across every month, with comparable rules. If your schema has no series layer, you rebuild that grouping with string matching on titles, and it breaks the first time a venue rewords a question.
Not every venue exposes a series object. Where it is absent, you infer one: same settlement source, same cadence, same question template. Store the inferred series with a flag that says it was derived, not supplied.
Event: one instance of something happening
An event is a specific occurrence: one game, one month’s rate decision, one election. It is the natural parent for a set of related markets. Polymarket’s catalog follows this pattern. A Gamma API walkthrough describes an event as a group of one or more markets that share a question theme, with fields for slug, title, end date, active and closed flags, volume and tags.
Two practical points follow from that:
The event’s end date is not necessarily each market’s resolution time. Treat them as separate timestamps.
An event can contain mutually exclusive markets (who wins) or independent ones (several thresholds). Record which, because it changes how probabilities should sum.
Market: one tradable question
A market is a single question with its own order book. On Polymarket, per the same walkthrough, a market is a specific Yes/No outcome with its own order book and token IDs. On Kalshi, the tiers run series, event, then market ticker, and the market is the contract you actually trade.
The market is where price, liquidity, spread and volume live. It is also where resolution rules attach. Two markets with near-identical titles and different rules are different markets, full stop.
Outcome: one side of the question
Outcomes are the priced sides of a market. Binary markets have two. Categorical events are usually modeled as several binary markets under one event. Scalar and bucketed designs add a further wrinkle: each bucket is its own market, yet the buckets form a distribution.
Keep the outcome as its own row. It gives you a stable place to hang a token ID, a label, a last price and a resolved value, and it lets a single query handle binary and multi-outcome designs alike.
How venues name the layers
The same concept appears under different labels. A mapping table is the first artifact worth writing down.
Canonical layer | Polymarket | Kalshi | What to store |
|---|---|---|---|
Series | Not a first-class object in the catalog | Series (ticker) | Native ID, or a derived series key with a derived flag |
Event | Event (slug) | Event (ticker) | Native ID, title, start and end times, mutual-exclusivity flag |
Market | Market (with token IDs) | Market (ticker) | Native ID, question text, rules text, status |
Outcome | Outcome token | Yes/No side | Label, token or side ID, last price, resolved value |
Treat the Limitless column as something you fill from its own documentation during integration. Do not assume it matches either of the other two. Our venue landscape overview covers how the platforms differ in structure and regulatory posture.
Descriptive axes: keep them separate
Structure tells you what contains what. Descriptive fields tell you what a market is about and how it behaves. The common mistake is collapsing them into one tag array.
Category and subcategory
Venues ship their own tag systems. Polymarket’s tags carry numeric IDs, with top-level tags such as Sports, Politics and Crypto, and narrower ones such as NBA or Election, as the Gamma walkthrough lists. Those tags are venue vocabulary. Map them into your own two-level category tree, and store the original tags unchanged next to it.
Why two levels? Because analysts ask both “all sports” and “all NBA totals.” A flat list forces either too many categories or too little resolution. Note that crypto here means a market’s subject matter, such as a price threshold question, and is a category like any other, not a topic of this guide.
Resolution type
Record how the question is decided:
Data release (a statistical agency publishes a number)
Official result (an election authority, a league)
Price reference (an index or exchange print at a given time)
Discretionary (a committee or oracle process decides)
Resolution type predicts dispute risk, timing and the shape of the information flow before settlement. It is one of the best features for grouping markets in a model.
Time horizon
Store at least three timestamps: market open, last trading time, and expected resolution. Derive a horizon bucket (intraday, days, weeks, months, long-dated) from them rather than hand-labeling. Several “edges” documented in the research literature, such as longshot effects, behave differently by horizon, so this field earns its place.
Settlement source
Name the authority the market defers to: a specific agency release, a named sports data provider, a certified result. Two markets with the same settlement source and the same threshold are candidates for a cross-venue pair. Two with different sources are not, however similar the titles.
Structure type
Flag binary, categorical (mutually exclusive set), threshold ladder, bucketed scalar, or combinatorial. This is the field that tells your code whether to normalize probabilities across siblings.
Canonical IDs: the part that makes it usable
A taxonomy without stable identifiers is a diagram. The practical recipe has four rules.
Mint a canonical ID per layer at ingestion. One for the series, event, market and outcome. Never reuse them.
Keep the native IDs as attributes. The Polymarket slug and token IDs, the Kalshi tickers, stored verbatim.
Make matches explicit records. A cross-venue match between two markets is a row with a method, a confidence and a timestamp, not an implicit join.
Never edit, only supersede. If a market is reclassified, write a new version and close the old one. Backtests then reproduce what you knew at the time.
The approach is the same one we describe in our guide to canonical IDs for cross-venue data, and our metadata schema guide lists the fields we would keep on each record.
A minimal record
{ "canonical_market_id": "mkt_01H...", "canonical_event_id": "evt_01H...", "canonical_series_id": "ser_01H...", "series_derived": false, "venue": "kalshi", "native_ids": { "market_ticker": "...", "event_ticker": "...", "series_ticker": "..." }, "category": ["economics", "inflation"], "venue_tags": ["..."], "structure_type": "threshold_ladder", "resolution_type": "data_release", "settlement_source": "...", "opens_at": "...", "closes_at": "...", "resolves_at": "...", "taxonomy_version": 3 }
The field names are illustrative. The principle is that every layer has an ID, every venue-native value is preserved, and the version is part of the row.
Matching events across venues
Once each venue is mapped, the next question is which markets are the same question. A defensible matching pipeline runs in stages:
Filter by category and structure type. Only compare like with like.
Filter by settlement source and resolution window. Different authority or different date means no match.
Compare thresholds and wording. Normalize units, dates and direction (above or below).
Score and label. Record an exact, near or related label with a confidence, and keep related matches out of any price-gap calculation.
Review the edge cases. Sample the borderline pairs by hand before trusting the rest.
Only the exact tier should feed spread or arbitrage work. Our measurement guide to cross-venue price gaps covers what to do after a pair is confirmed, including why quoted gaps and executable gaps differ.
Failure modes the taxonomy prevents
Double counting. Summing event volume and market volume in one total. Fix: separate layers, aggregate at one layer only.
Phantom arbitrage. Pairing markets with different settlement sources or cutoffs. Fix: match on source and window before price.
Silent category drift. A venue edits a tag and a filter loses rows. Fix: keep native tags, filter on your own tree.
Broken series history. A title changes, and last month’s market no longer joins this month’s. Fix: series IDs independent of text.
Unreproducible backtests. A reclassification rewrites the past. Fix: versioned records. See our note on reproducible workflows across datasets.
Taxonomy for agents and bots
An agent reasoning over markets needs the taxonomy even more than a human does, because it cannot glance at a page and infer that two questions differ. Give it structured fields: structure type, resolution type, settlement source, horizon. Prompts that rely on titles alone invite confident mistakes.
For tool design, expose the layers as separate calls: list series, list events in a series, list markets in an event, fetch outcomes. That keeps responses small and lets the agent walk the hierarchy the way an analyst would. Event categories are also what let an agent specialize. Work on AI agents predicting sports event results shows why a clean event listing is the first input such a system needs. Our agent data guide goes into response shaping.
For bots, the series layer is the unit of deployment. You write a strategy for “weekly jobless claims” once and let it pick up each new event automatically. On Kalshi that flow is series, then events, then markets. Bots that hard-code individual market tickers need manual upkeep every cycle.
Versioning the taxonomy itself
Your category tree will change. A new venue launches, a topic becomes large enough to deserve its own branch, a mapping turns out wrong. Plan for it:
Give the taxonomy a version number and stamp it on every classified record.
Keep a mapping table from venue tags to your categories, with effective dates.
When you remap, write new rows rather than updating, and keep both versions queryable.
Publish a short changelog internally. Researchers will ask why a number moved.
Our perspective
Most teams treat classification as a cleanup step. We treat it as infrastructure. When we normalize Polymarket, Kalshi and Limitless into one schema, the taxonomy is what lets a Smart Money wallet’s activity, a Trader Skill Score and a cross-venue price gap all refer to the same underlying question.
Our position is that a venue-neutral taxonomy has to sit outside any single exchange. A venue’s own tags serve that venue’s interface. A research or trading pipeline needs identifiers and categories that stay stable when a venue renames something, and that preserve the native fields so nothing is lost.
That is why we pair canonical IDs with the original venue identifiers, and why we build on a large historical record rather than only live data. A taxonomy you cannot apply to history is a taxonomy you cannot test.
Dean
Using this with the Assymetrix Data API
If you would rather not maintain the mapping layer yourself, our Data API gives developers, quants and agents unified access to cross-venue prediction market data through a single integration, built on roughly 1.5 terabytes of history. Canonical IDs and normalized market schemas are part of what it provides. Details are on the Data API page, and the real-time and historical feed guide walks through the endpoints.
The API has free and paid tiers. For current plans and access terms, see the Assymetrix site.
Implementation checklist
Define the four layers and write the mapping table for each venue.
Choose your category tree, two levels deep, and map venue tags into it.
Add resolution type, settlement source, structure type and three timestamps.
Mint canonical IDs and keep native IDs verbatim.
Build matching as explicit, scored, versioned records.
Restrict price-gap and arbitrage logic to exact matches.
Stamp every record with a taxonomy version.
Test against history before going live.
FAQ
What is an event taxonomy in prediction markets?
It is the classification scheme that organizes listings into layers: series, events, markets and outcomes, plus descriptive fields such as category and resolution type. It lets you compare, group and join markets reliably. Each venue has its own version, so cross-venue work needs a shared one.
What is the difference between an event and a market?
An event is a specific occurrence, such as one game or one rate decision. A market is a single tradable question about it, with its own order book. One event can hold many markets, which is how Polymarket’s catalog describes the relationship.
Do all venues have a series layer?
No. Kalshi documents series as templates for recurring events. Where a venue does not expose one, you can derive it from cadence, wording template and settlement source. Mark derived series so they can be audited.
Should I use venue tags as my categories?
Keep them, but do not rely on them alone. Store the original tags unchanged and map them into your own category tree. That way a venue renaming a tag does not change your filters or your backtests.
How do I match the same event across venues?
Compare category, structure type, settlement source, resolution window and threshold before any text similarity. Label matches exact, near or related, and use only exact matches for price-gap analysis.
Sources
Other Blog
