Design a resolvable question
A forecasting question needs a rule that a later adjudicator can apply without knowing which outcome the forecaster preferred. Define one proposition, its time window, the source that establishes the outcome, and what happens when the necessary observation is missing.
“Will the launch go well?” is not operational. “Will release X appear in the official general-availability archive strictly before timestamp T?” is closer: it identifies an event, a boundary, and an observation source. Whether that source is complete and accessible still needs investigation.
Freeze the contract
workflow::Question contains:
| Field | What to decide |
|---|---|
id, version | Stable target identity; increment the version when its meaning changes |
proposition | The exact claim being forecast |
opens_at, deadline | Allowed forecast window, including the start and excluding the deadline |
resolve_after | Earliest time an adjudication is permitted |
yes_rule, no_rule | Observable conditions establishing the two outcomes |
void_rule | Administrative exclusion conditions |
resolution_sources | Ordered source precedence, highest priority first |
The constructor checks nonempty fields, a positive version, and an ordered timeline. It does not parse the prose into a legal or causal predicate, check source accessibility, or prove that the yes/no rules form a complete partition. A source must be in the declared list for a resolution to be accepted; the adjudicator explains how precedence was applied.
Rehearse boundaries
Before forecasting, apply the proposed rules to hypothetical cases:
- The event happens exactly at the deadline. Does “before” exclude it?
- A source publishes after the deadline but documents an earlier event. Which timestamp controls the outcome?
- The product is renamed. Does the frozen identity still apply?
- The source stops publishing. Is the case unresolved, void, or resolvable from a fallback source?
- A report is revised. Does the first release or the revised value count?
Missing observations are not automatically evidence of “no.” Use unresolved status while the observation is insufficient. Void is an administrative state, not a third binary outcome to which an ordinary yes/no probability is assigned.
Forecasts and decisions
“Should we migrate the service?” is a decision. “Will the migration exceed its approved downtime window?” is a forecastable event. A small probability can justify mitigation if the loss is large; keep the event estimate separate from the utility calculation.
The storage layer freezes the question version. Editing a deadline or predicate means creating a new version and making that change visible. A correction to the arithmetic belongs in the forecast history rather than changing the question.