Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

indicator

Validate a two-branch indicator model and measure expected information gain.

Contract

The implied prior must match the stated prior within the declared tolerance. Information is in nats; sensitivities are ordered chance, if_yes, if_no. Association is not an intervention effect.

Fields

FieldTypeRequired
indicatorIndicatorYes
op"indicator"Yes
stated_priorProbabilityYes
tolerancenumberYes

This operation needs no existing question or forecast. Use --memory for a calculation-only session.

Request

Send this object on one line. It is expanded below for readability.

{
  "version": 1,
  "id": "example",
  "command": {
    "op": "indicator",
    "indicator": {
      "chance": 0.5,
      "if_yes": 0.8,
      "if_no": 0.3
    },
    "stated_prior": 0.55,
    "tolerance": 1e-12
  }
}

Response

This response is generated by executing the example against the current binary. Commit timestamps, when present, are shown as <runtime UTC seconds>; the actual protocol returns integer UTC seconds.

{
  "version": 1,
  "id": "example",
  "result": {
    "implied_prior": 0.55,
    "information_gain_nats": 0.1325054509170478,
    "sensitivity": [
      0.5,
      0.5,
      0.5
    ]
  }
}

Verification

The documentation gate executes the setup and request, then checks the following result fields against independently specified expectations:

JSON pointer within resultExpected
/implied_prior0.55
/sensitivity/00.5

Float comparisons use a 1e-12 tolerance. Request schema validation and cross-record validation still apply. See errors and recovery for failure handling.