Query-based outcome resolution

A query outcome policy lets the authorized outcome job read a published project query after a prediction becomes due. It is separate from the evidence query used to make the prediction. The outcome query must explicitly return a verdict and real assertion evidence; the presence of a row is not an occurrence.

What to prepare

For equipment failure, capture and review actual incident/monitoring assertions in the prediction project. Define how those observations establish occurred, not_occurred, unknown, ambiguous or unresolvable for the exact equipment/window. Publish an outcome query that selects that subject's relevant observation and produces one explicit verdict row.

The supported output contract is:

{
  "outcome_status":"occurred",
  "outcome_evidence_assertion_ids":["<ACTUAL_PROJECT_ASSERTION_UUID>"],
  "outcome_notes":"Incident record establishes an unplanned failure with two hours downtime within the prediction window."
}

IDs must be actual UUIDs for assertions in the same project. Placeholder text is not accepted. Multiple rows, no row, an incomplete result or missing evidence IDs leave resolution pending. A default verdict in policy configuration does not establish an outcome.

Configure the policy

You need a Semogram account with project access, a completed typed probability forecasting setup and a published outcome query. Its input schema must accept subject_ref, prediction_id, horizon and params; the runtime supplies them. Any additional configured top-level strings can interpolate subject_ref, prediction_id and horizon.

{
  "kind": "query",
  "queryId": "<PUBLISHED_OUTCOME_QUERY_UUID>",
  "queryReleaseId": "latest",
  "limit": 25,
  "input": {},
  "mapping": {
    "verdict_path": "$.outcome_status",
    "evidence_assertion_ids_path": "$.outcome_evidence_assertion_ids"
  }
}

This object belongs in Outcome resolution/evaluationPolicy, not a standalone call. In the forecaster Edit page, enter it in Outcome resolution and save. Through forecaster_update, supply both outcomeResolution and evaluationPolicy consistently with this object and a unique idempotencyKey. The explicit published release is pinned when the new forecaster version is saved. Later predictions retain their policy snapshot; changing the forecaster does not rewrite old policies.

The mapping paths are dot-separated object paths. If omitted, the default names outcome_status/outcomeStatus and outcome_evidence_assertion_ids/outcomeEvidenceAssertionIds are used. The verdict must be one of the accepted outcome states with at least one evidence UUID.

Understand the job

The authorized outcome tick claims bounded pending work. It executes the pinned outcome release, checks completeness, parses a single verdict, checks project assertion references and records an immutable query evaluation at the tick's observation time. It then records resolution evidence on the prediction. Query failure or inadequate evidence leaves Pending with diagnostic notes; it is not automatically marked Unresolvable.

For automatic numeric/category scoring, the current tick does not forward an observedValue from its verdict row. Use explicit MCP evaluations for those values rather than assuming this event-verdict flow can score downtime hours or category labels. This guide's automatic example is a probability event.

Verify the policy before scheduling

Execute the outcome query manually for known equipment and a real closed window. Verify its assertions support the event definition and absence verdicts use adequate monitoring. Then inspect a due prediction's evaluation record, evaluator query-release identity and outcome notes. A correctly shaped row cannot by itself guarantee a correct real-world verdict.

Investigate unresolved work

Outcome operations explains due-window review, query diagnostics, immutable policy limits and manual corrections. A failed resolution attempt should be investigated separately from forecast execution.