Where Can I Find Historical Prediction-Market Definitions?

The important distinction is between finding an old definition and proving what governed settlement. A dataset can preserve the text that was collected, but the venue’s rules may explain which field controls, how a correction is handled, or what happens when the named source is unavailable. A historical archive is therefore a research starting point, not an automatic replacement for the original terms.

1. Start with a downloadable definition dataset

A market page is designed for reading one question at a time. A dataset is more useful when you want to compare wording across hundreds or thousands of questions, filter by date or category, or find examples of a particular resolution pattern. The 2084Collective dataset viewer currently describes a train split of about 50,000 rows in Parquet, a column-oriented data format. The page shows two venue values and fields including platform, market_id, question, description, resolution_source, winning_outcome, outcomes, close_time, market_type, and original.

This dataset is useful precisely because it is not only a list of venue names. Its rows put the short display question next to the longer text and the settlement-related fields. It is still a snapshot with its own coverage and collection date. Check the current dataset page before citing its row count or treating it as complete.

If you need a larger, regularly refreshed catalog, Kingsets publishes downloadable CSV files and queryable Google BigQuery tables for Polymarket and Kalshi series, events, markets, and trades. Its own data guide says that the Polymarket market list covers the full historical catalog, while the Kalshi catalog is still being ingested. That makes it useful for discovery and cross-venue analysis, but not a reason to assume that every historical Kalshi market is present.

2. What you can actually find in the row

Treat the downloaded row as a compact research record. The following fields answer different questions and should not be collapsed into one generic idea of “the market.”

Field or group	Description
question or title	The short display question a reader saw; read it alongside the description or rules to understand the settlement meaning.
description or rules	Criteria, boundaries, exceptions, context, and any venue-specific resolution language. Historical copies may not show every amendment.
resolution_source	The source named in the collected record; inspect the description and original payload to determine how it was intended to be used.
outcomes and final result	The outcome set and the settlement state recorded by the venue, without necessarily explaining why that outcome was selected.
Dates and status	Opening, closing, expiration, determination, and settlement timing; these timestamps may represent different lifecycle events.
market_id and original	Identifiers for joining records and inspecting venue-specific fields; cross-venue equivalence still requires review.

One field deserves special caution: resolution_source. A single URL can be a useful clue, but a source hierarchy is an ordered rule: source A controls first, source B is used if A is unavailable, and source C may resolve a defined data failure. The row may contain only source A, or a general homepage rather than the exact publication. Read the description and original payload for the actual fallback language.

3. How the same concepts appear at different venues

The downloadable table gives you a common place to begin, but the venues do not use identical data models. The field names below are a map for reading the records, not a claim that the contracts have the same legal or operational structure.

1. Polymarket. Its official market API documents fields such as question, description, resolutionSource, startDate, endDate, closedTime, outcomes, and identifiers including conditionId and questionID. The venue’s resolution documentation says that the market’s pre-defined resolution rules specify the resolution source, end date, and treatment of edge cases. Use the title to find the record, but use the description and rules to understand how it resolves.
2. Kalshi. Its official market response includes title, subtitle, rules_primary, rules_secondary, open_time, close_time, expected_expiration_time, latest_expiration_time, result, and settlement_ts. The Get Market documentation is the useful field map. Its market lifecycle documentation explains why a market can close before it is determined and why a determined result can still be in a settlement period.
3. Manifold. Its public API documentation describes a market record with question, description, createdTime, closeTime, isResolved, resolution, and resolutionTime. Because questions are user-created and the description can carry the criteria, the record often looks more like a creator-authored specification than an exchange product with a separate formal rules field.

If you also need forecasting questions that are not traded contracts, keep them in a separate category. For example, Metaculus documents question-data downloads and resolution values, but its access conditions and question model are different from a market venue’s contract record. Do not use a forecasting-question export as if it were automatically a trading-market specification.

4. A practical source hierarchy

There is no universal source hierarchy shared by every venue. The following is my default research order when reconstructing a historical market. It separates the question “what did the contract say?” from “what happened in the world?” and “how did the venue process settlement?”

1. Market-specific terms effective at the time. Start with the full description, rules, source instructions, outcome set, and edge-case language for that market. A current page may not preserve the wording that was visible when the market was open, so retain the historical copy and its collection date.
2. The venue’s official record and rulebook. Use the official API object, market page, product specification, or rulebook to interpret field names, amendment rules, close and expiration semantics, disputes, and final settlement. A normalized archive can point you to the record; it does not define the venue’s rules for you.
3. The named primary source. For the event itself, follow the source named in the market: an official statistics release, election authority, sports governing body, court record, company filing, or other specified publication. Record the exact page, dataset, release date, and relevant value where possible.
4. The venue’s settlement record. Compare the final result, settlement timestamp, and any determination or dispute status with the market terms. The result tells you what the venue recorded; it does not by itself explain whether a source correction, fallback, or manual review was involved.
5. Third-party archives and research writing. Use downloadable datasets, academic papers, data journalism, and screenshots to locate examples, preserve material that may disappear, and compare venues. Cite the archive as an archive, not as the authority that originally defined or settled the contract.

5. Reconstruct one historical definition

A repeatable review can be small. For each example, keep a compact record with the following steps:

1. Identify the exact unit. Save the venue, market_id or ticker, market URL, event or series identifier where available, and the dataset revision or download date. Similar display questions can belong to separate markets with different thresholds, dates, or outcomes.
2. Read short and long text together. Put the display question beside the description or rules. Highlight every parameter: subject, comparator, threshold, unit, jurisdiction, time window, and outcome label.
3. Extract the source rule. Record the primary source, any fallback sources, the exact publication or data field, the controlling timestamp, and the treatment of revisions, missing data, cancellation, or ambiguous results. If the archive only offers one URL, mark the hierarchy as incomplete rather than inventing one.
4. Separate the clocks. Keep open time, last trading time, observation end, expected expiration, final determination, and settlement time as separate fields. They answer different questions.
5. Verify the result. Compare the underlying publication with the venue’s recorded outcome. If they appear inconsistent, preserve the discrepancy and investigate the venue’s stated rule before correcting the dataset.

6. Common mistakes

• Treating the title as the full contract instead of reading the description or rules.
• Treating a single resolution_source URL as a complete source hierarchy.
• Assuming that close time, event deadline, expiration, and settlement timestamp are interchangeable.
• Comparing prices or final outcomes without first checking whether the questions use the same event, date, threshold, and outcome set.
• Assuming an archive’s normalized field names preserve every venue-specific rule or amendment.
• Replacing a historical definition with the current market page without recording the change.

7. From historical examples to a new specification

Historical records are most useful as examples of design decisions. They show how different venues phrase a display question, expose a threshold, define an outcome, name a source, and handle an early event or delayed publication. They do not automatically provide a reusable template or settle the right wording for a new question.

For a new event contract, carry the useful fields forward deliberately: the reader-facing question, the underlying event, parameters, mutually exclusive outcomes, observation window, source hierarchy, resolution criteria, settlement calculation, and edge cases. The guide to creating a new prediction market explains that specification structure in more detail. If the question is for a curated venue, the listing proposal guide explains how to present the source, timing, and edge cases for review.

Sources and citation note

The dataset fields and access descriptions above were checked on 30 August 2026. Dataset coverage, file versions, API fields, and access rules can change. The practical source hierarchy and reconstruction workflow are my interpretation of how to use these records carefully; they are not universal venue rules.

• 2084Collective: prediction-markets-historical-v2 Historical Parquet dataset with normalized definition fields and original venue payloads for Polymarket and Kalshi records.
• Kingsets Downloadable CSV and BigQuery data guide for Polymarket and Kalshi series, events, markets, and trades.
• Polymarket: List markets Official market fields and identifiers.
• Polymarket: Resolution Official explanation of resolution sources, end dates, and edge cases.
• Kalshi: Get Market Official market response fields, including rules and settlement values.
• Kalshi: Market Lifecycle Official explanation of close, determination, dispute, and settlement states.
• Manifold API documentation Official public API field descriptions for question, description, timing, and resolution.
• Metaculus API documentation Official question-data and download documentation for a related forecasting service.

This article provides technical and conceptual guidance. It is not legal advice, regulatory advice, investment advice, a recommendation to trade, or a determination that any particular market, dataset, or source is complete or authoritative.