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
| Field | Type | Required |
|---|---|---|
indicator | Indicator | Yes |
op | "indicator" | Yes |
stated_prior | Probability | Yes |
tolerance | number | Yes |
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 result | Expected |
|---|---|
/implied_prior | 0.55 |
/sensitivity/0 | 0.5 |
Float comparisons use a 1e-12 tolerance. Request schema validation and cross-record validation still apply. See errors and recovery for failure handling.