Previous value: -"Every rule considered: `id`, `state` (pass, fail or unknown), `checks` and `says`. THE TWO SENTENCES ARE DIFFERENT THINGS and the distinction is the audit trail. `checks` is the QUESTION the rule asks and never moves; `says` is WHAT WE FOUND and follows the state, so a failing rule reads as a failure. Until 2026-10-13 `says` carried the question in every state, which meant a `fail` arrived beside the claim it had just refuted — a model reading the prose rather than the state got the opposite of the decision. Read `state` to decide and `says` to explain; they can no longer disagree."New value: +"Every rule considered: `id`, `state` (pass, fail or unknown), `checks` and `says`. THE TWO SENTENCES ARE DIFFERENT THINGS and the distinction is the audit trail. `checks` is the QUESTION the rule asks and never moves; `says` is WHAT WE FOUND and follows the state, so a failing rule reads as a failure. Until 2026-10-13 `says` carried the question in every state, which meant a `fail` arrived beside the claim it had just refuted — a model reading the prose rather than the state got the opposite of the decision. Read `state` to decide and `says` to explain; they can no longer disagree. A FAILED RULE CARRIES `detail` WHERE IT CAN: `observed` is what we read in the rule’s own vocabulary, `accepted` is what the policy would have taken, and `failedCondition` is the sentence replacing the generic one. On `controller-risk-within-policy` that matters more than anywhere: a vault can read `controller.level: low` in vault_check and still fail here, because the LEVEL says how dangerous the arrangement is and the BAND says what it is; a timelock with no guardian is `thin`, conservative accepts `checked` only, and both readings are right. The detail says so rather than leaving a reader to find a computational error that is not there. SINCE 2026-10-11 A POLICY JUDGES THE RISK LEVEL, NOT ONLY ITS TRUSTWORTHINESS. `risk-band-is-supported` asks whether the band survives what we could not read; `risk-band-within-policy` and `controller-risk-within-policy` ask whether the band and the control we DID read are ones this policy will commit capital against. Conservative will not allocate into a band worse than moderate, nor where control is `thin` (one party able to move the money), and returns `review` rather than `abstain`, because a band we read as high is a finding about the vault and not a gap in our reading. Permissive declares neither threshold and is unchanged. This closed a real defect: a vault our own vault_check called high risk with 0.5% withdrawable used to come back `allow`, because every rule about the AVAILABILITY of risk data passed."

Previous value: -"WHICH ACCEPTANCE QUESTIONS THIS POLICY PUT AT ALL: `riskBand`, `controller`, `amount`, as booleans. READ THIS BEFORE ACTING ON `decision`. FALSE is the dangerous value and the reason the field exists: it means the question was never put, which is NOT a question that passed. `permissive` returns `allow` on a vault that lost 92.8% of its value because it declares no risk ceiling, and a client reading only `decision` cannot see that. Derived from what the POLICY declares and never from how the subject turned out, so a refusal and a clean pass under one policy carry identical flags."New value: +"WHICH ACCEPTANCE QUESTIONS THIS POLICY PUT AT ALL: `riskBand`, `controller`, `exitRecord`, `amount`, as booleans. READ THIS BEFORE ACTING ON `decision`. FALSE is the dangerous value and the reason the field exists: it means the question was never put, which is NOT a question that passed. `permissive` returns `allow` on a vault that lost 92.8% of its value because it declares no risk ceiling, and a client reading only `decision` cannot see that. `exitRecord` is whether the policy weighed HOW OFTEN THE EXIT HAS BEEN SHUT over the days we watched, as against how it reads at the last reading: 20 vaults holding $190.8M read as open today and were shut on more than a tenth of the days we have watched them, so a policy that never asked has not cleared them. Derived from what the POLICY declares and never from how the subject turned out, so a refusal and a clean pass under one policy carry identical flags."

Added value: +{
+  "description": "How current this answer is and what it was read from: `freshness` and the ages behind it. Present on every answer from this server, whatever the tool.",
+  "type": "object"
+}

Added value: +{
+  "description": "Anything the server wants a caller to know about THIS answer before acting on it. Empty is the normal case and is not a guarantee.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

Added value: +{
+  "description": "WHICH ACCEPTANCE QUESTIONS THIS POLICY PUT AT ALL: `riskBand`, `controller`, `amount`, as booleans. READ THIS BEFORE ACTING ON `decision`. FALSE is the dangerous value and the reason the field exists: it means the question was never put, which is NOT a question that passed. `permissive` returns `allow` on a vault that lost 92.8% of its value because it declares no risk ceiling, and a client reading only `decision` cannot see that. Derived from what the POLICY declares and never from how the subject turned out, so a refusal and a clean pass under one policy carry identical flags.",
+  "type": "object"
+}

Added value: +{
+  "description": "What the policy is FOR. `risk-and-evidence` puts questions about the level AND about what we could read. `evidence-availability` asks only whether we could read enough — which is what `permissive` is: an availability-of-evidence policy rather than an investment risk policy. An `allow` from one is not an `allow` from the other.",
+  "enum": [
+    "risk-and-evidence",
+    "evidence-availability"
+  ],
+  "type": "string"
+}

Previous value: -"Every rule considered, each pass, fail or unknown. The audit trail for the decision."New value: +"Every rule considered: `id`, `state` (pass, fail or unknown), `checks` and `says`. THE TWO SENTENCES ARE DIFFERENT THINGS and the distinction is the audit trail. `checks` is the QUESTION the rule asks and never moves; `says` is WHAT WE FOUND and follows the state, so a failing rule reads as a failure. Until 2026-10-13 `says` carried the question in every state, which meant a `fail` arrived beside the claim it had just refuted — a model reading the prose rather than the state got the opposite of the decision. Read `state` to decide and `says` to explain; they can no longer disagree."

Added value: +{
+  "description": "Rule ids YOU will not act without, e.g. [\"quoted-payee-matches-proposal\",\"live-price-matches-proposal\"]. The policy is OUR view of what matters; this is yours. Any one of them that does not reach a verdict — because we could not read it, or because it never applied to what you sent — turns the answer into ABSTAIN instead of ALLOW. It can only ever make the answer more conservative: a required check that passes changes nothing, and a real objection stays a REVIEW rather than being buried as an abstain. An id we do not hold is NAMED in `required.unknownIds` rather than ignored, because a caller whose requirement was never looked at must not read `allow` as it having been met. `list_policies` has every id.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

Added value: +{
+  "description": "The same coverage, PER QUESTION: counterparty, payment-intent, service, capital. Read this rather than the single `coverage` when the action moves money. The denominator is the rules the policy holds for that area, NOT the ones that happened to apply — so an area where nothing could be checked reports `none`, which is the fact, instead of reporting high coverage of nothing.",
+  "items": {
+    "type": "object"
+  },
+  "type": "array"
+}

Added value: +{
+  "description": "Whether this payment was checked against WHAT IT IS BUYING, in one field. `not-verified` means the policy holds such rules and none of them ran, which on a payment is almost always a missing `resource`: the counterparty may have an excellent record and nothing has compared this amount to this service. `verified` means at least one reached a verdict. `not-applicable` means the policy asks nothing about it, or the action is not a payment.",
+  "type": "object"
+}

Added value: +{
+  "description": "Present only where you sent `requiredChecks`. `met`, `unmet` and `unknownIds`, with a sentence. An `unmet` entry is why the decision is ABSTAIN.",
+  "type": "object"
+}

Added value: +{
+  "description": "Rules this PROPOSAL does not raise, each with `why` and what to send to have it checked. Distinct from `missingEvidence`, which is a gap in our record: a payment naming no `resource` has no listing to be found in, so those rules do not apply and do not lower coverage. Send `resource` and two more checks run, both decisive.",
+  "items": {
+    "type": "object"
+  },
+  "type": "array"
+}

Added value: +"What a decision here is and is not. `allow` means no rule objected under this policy at this coverage, which is not a statement that the action is safe."

Added value: +"The decision in one sentence, naming the rules that drove it. Written to be shown to whoever authorises the action."

Added value: +{
+  "description": "What each decision word means, so a caller never has to guess. Read it before treating `allow` as approval or `abstain` as a clean result.",
+  "type": "object"
+}

Added value: +{
+  "type": "string"
+}

Added value: +{
+  "description": "The policy applied: its intent, its ceiling and the coverage floor below which it abstains.",
+  "type": "object"
+}

Added value: +{
+  "description": "What you asked about, read back, so a typo is visible before you act on the answer.",
+  "type": "object"
+}