Analyze a prediction market with AI and traceable sources

Start with the rules, not the headline

A prediction market question title is not the contract. The binding terms specify the resolution source, the exact deadline, the edge cases and what happens if the source is unavailable. On Polymarket, ordinary binary markets resolve through UMA, while Up/Down markets use a Chainlink time-weighted average price (TWAP) and compare the final value against the starting value: final at or above start means UP, lower means DOWN. Do not generalize that mechanism to every duration or every market.

Before asking an AI anything, freeze a record: the exact question text, the retrieval timestamp, the named resolution source, the deadline and any special fallback. This record lets you later check whether the AI used the real rule or an invented one. It also separates a market with a clear settlement path from one where the rules themselves are contested.

Prices are observations, quotes are what you can trade

The displayed price on a market is usually the midpoint of the best bid and best ask. When the spread is wider than 0.10, the platform may instead show the last trade. Neither is a promise that you can buy or sell at that number. The executable quote, the depth available and the moment you observed it are what matter for any calculation.

Treat every price you feed an AI as dated evidence, not as a current fact. If you copy a midpoint into a prompt and the model builds a thesis on it, you have anchored the analysis to a number that may not be tradable. Record the spread and the top of book alongside the midpoint so you can later test whether the assumed entry price exists in size.

Market orders consume multiple price levels, so a large order slips beyond the best quote. That slippage is a cost, not a rounding detail. A methodical private trader should model it explicitly rather than assume the midpoint fills, and should note that the midpoint itself is not an executable guarantee.

The 4-step AI workflow

This workflow is an authored illustration, not an empirical study. Step one: freeze the question, timestamp and source record so the analysis has a fixed object. Step 2: retrieve dated primary evidence and label each item as an observation or an assumption. Step 3: ask the model for competing mechanisms that could drive the outcome, base-rate context, and the source IDs behind each claim. Step 4: independently recalculate anything the model asserts, because a persuasive answer is not a demonstrated edge.

The separation between observation and assumption is the core discipline. An observation is a dated fact you can point to, such as a rule text or an order book snapshot. An assumption is your belief about how those facts translate into a probability. Mixing them produces a confident narrative with no audit trail, which is exactly what a traceable-source workflow is meant to prevent.

When you move from drafting to building your own models or pulling data programmatically, the same discipline carries over. You can see it applied in probability forecasting with AI and in prediction market data and API access, which cover the modeling and retrieval steps respectively.

A reusable prompt that asks for mechanisms, not confidence

The prompt below is concrete and reusable, and it uses a neutral hypothetical event. It asks for competing mechanisms, a base-rate reference, explicit assumptions and source identifiers. It does not ask the model to predict a price or promise a profit. Replace the bracketed sections with your frozen record.

Treat the model output as a draft list of hypotheses and prompts for your own verification. If the model returns a source ID, open it and check the date, the exact wording and whether it actually supports the claim. If it returns a base rate, ask which reference class it used and whether that class matches the resolution rules you froze earlier.

Worked decision: when a .6 belief meets a .4 quote

This case is explicitly illustrative. Suppose you assign a .6 probability to a neutral hypothetical event. The executable ask is .40 and you buy 100 shares, so the stake is 100 times .40, which equals 40. Costs are 2. Expected value is .6 times 100 minus 40 minus 2, which equals 18. The win outcome is 100 minus 40 minus 2, which equals 58. The loss outcome is 0 minus 40 minus 2, which equals negative 42. These figures come from the authored example, not from a study.

The negative 42 is the part a persuasive AI answer tends to bury. The edge in this calculation exists only if your .6 is better grounded than the market's implied .4, and only if the 100 shares actually fill near .40 after slippage. The midpoint is not an executable guarantee, and resolution can differ from the ordinary binary outcome: rare unknown or 50-50 resolutions can pay .50 per share rather than cancel or refund the trade. A positive expected value here is not a reason to buy; it is a hypothesis to test against the rules and the real order book.

The practical test is to change one input at a time. Raise the entry price to .50 and the edge shrinks. Add slippage and costs and it can vanish. If your advantage disappears under small, plausible changes, you are probably looking at a narrative, not a durable edge. The same arithmetic a trader uses to size a portfolio position can be applied to a single market: bottom-line account value after the event, not the confidence of the narrative, is what matters. For the general version of this arithmetic, see expected value calculations for prediction markets.

Where this workflow breaks down

The model can misread resolution rules, invent a source, or anchor on a stale midpoint. Rules differ by market: UMA handles ordinary prediction markets, while Up/Down markets rely on a Chainlink TWAP whose start and end values come from the same asset stream, and exchange candles can differ from that stream. Any of these differences can flip a conclusion.

Liquidity is another failure point. A quote can exist at the top of book but disappear when you try to execute size, and a wide spread means the displayed number is the last trade rather than a tradable price. Your frozen record should state the depth you actually observed, or admit that you do not know it.

Finally, AI confidence is not calibration. A fluent answer with a clean structure can still be wrong, and this workflow offers no guarantee of profit. Its only promise is traceability: a record you can re-check and a calculation you can reproduce.

Your next decision

Before you trade, answer 3 questions on one page. First, which source and deadline actually govern resolution, and have you read them? Second, what is the executable quote and depth right now, not the midpoint you saw earlier? Third, if your probability is wrong by a small margin, does the position still make sense after costs and slippage? If you cannot answer all 3, you are not ready to size the trade.

Then separate the 2 failure modes you can actually manage. A rule failure comes from not reading the resolution source or deadline, and it is fixed by freezing the record first. A price failure comes from treating a midpoint as a fill, and it is fixed by recording the spread and testing slippage. Neither fix requires better AI output; both require your own verification.

If the market resolves on a published source, verify that source before you verify the model. If the market uses a TWAP, confirm the asset stream and the comparison window before you model the outcome. Then write down the price at which your thesis stops working. That number, not the model's confidence, is your position size boundary.