Prediction Topics APIEvery prediction needs a defined question.

Separate the subject from the forecast

A topic identifies what a prediction concerns, such as energy demand or election participation. The forecast itself is a statement about an outcome under specified conditions. Keeping those layers separate prevents a content classification from being mistaken for a prediction.

Write the question in terms that could be resolved consistently. Ambiguous subjects lead to ambiguous comparisons. Two articles can discuss the same broad topic while predicting different variables, time periods, or geographic areas.

Make time part of the meaning

Record when a forecast was made and the period it concerns. A short-term estimate and a longer scenario are different records even when the headline uses the same words. Preserve the original time zone and distinguish a deadline from an observation window.

Avoid updating old forecast records in place when assumptions change. Create a revision with an explicit relationship to the earlier record. Historical context matters when readers want to understand what was known at the time.

Preserve the form of uncertainty

A probability, an interval, a scenario, and a qualitative statement express different things. Store the representation explicitly rather than squeezing every prediction into one numeric field. A missing probability should remain missing, not become an invented number.

Keep assumptions beside the record: the population, observation method, data availability, and any conditions attached to the claim. A classification system can make these fields visible without claiming to verify the forecast’s accuracy.

Define how a result will be resolved

A prediction record should explain what would count as the outcome and which evidence would be used to assess it. Consider revisions to underlying observations and cases where no decisive result becomes available.

Use topics to group comparable questions, then check comparability before aggregating. Mixing different horizons or definitions can make a collection look informative while obscuring the actual claims. A useful archive supports inspection of the original statement and its context.

An illustrative record

This example highlights fields worth discussing when you design your own contract. Define their meanings, allowed values, and review rules before an application relies on them.

{
  "topic_id": "energy.demand",
  "question": "Example demand scenario for a defined region",
  "horizon": "specified future period",
  "uncertainty_type": "scenario",
  "resolution_status": "unresolved"
}

Illustrative schema and example values; adapt them to your data and review process.

Questions about Prediction Topics API