[{"data":1,"prerenderedAt":9},["ShallowReactive",2],{"doc-verdicts":3},{"blocks":4,"markdown":8},[5],{"kind":6,"html":7},"html","\u003Cp>Every answer carries a \u003Ccode>status\u003C\u002Fcode>. There are exactly three, and the difference\nbetween them is the difference between three different things you should do next.\u003C\u002Fp>\n\u003Ch2 id=\"valid\">\u003Ccode class=\"chip chip--valid\">valid\u003C\u002Fcode>\u003C\u002Fh2>\n\u003Cp>The answer passed the check.\u003C\u002Fp>\n\u003Cp>\u003Ccode>result\u003C\u002Fcode> holds the artifact. \u003Ccode>verified_by\u003C\u002Fcode> identifies the version of the rules that accepted it.\n\u003Cstrong>Billable.\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>\u003Ccode class=\"chip chip--valid\">valid\u003C\u002Fcode> is a statement about the artifact, not about the world: it passed its\nformat's checks. A chart's \u003Ccode>data\u003C\u002Fcode> says whether its values came from your request\n(\u003Ccode>supplied\u003C\u002Fcode>) or were illustrative values you allowed (\u003Ccode>generated\u003C\u002Fcode>).\u003C\u002Fp>\n\u003Ch2 id=\"invalid\">\u003Ccode class=\"chip chip--invalid\">invalid\u003C\u002Fcode>\u003C\u002Fh2>\n\u003Cp>The check refused the answer. There is no \u003Ccode>result\u003C\u002Fcode>; \u003Ccode>reason\u003C\u002Fcode> says why as a\ncode you can branch on, and \u003Ccode>detail\u003C\u002Fcode> says it in plain language:\u003C\u002Fp>\n\u003Cdiv class=\"doc-table\">\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>\u003Ccode>reason\u003C\u002Fcode>\u003C\u002Fth>\n\u003Cth>Meaning\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>\u003Ccode>unsupported_feature\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>The request needs something this oracle cannot draw\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>chart_type_mismatch\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>The request names a kind of chart, and no chart of that kind passed in this format\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>no_valid_answer\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>Nothing that passed could be produced for this request; say more concretely what it should contain\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003C\u002Fdiv>\n\u003Cp>\u003Cstrong>Billable, and that is not a technicality.\u003C\u002Fstrong> The work was done, and a reliable\n"no" is the thing you are buying. An API that charged only for\nanswers it liked would have every incentive to loosen the rules until\neverything passed — which is precisely the failure mode a verdict exists to\nprevent.\u003C\u002Fp>\n\u003Cp>Retrying an identical intent may produce a different verdict, because the same\nintent can return a different artifact. Retrying it many times is a way to spend\ncredits.\u003C\u002Fp>\n\u003Cp>An \u003Ccode class=\"chip chip--invalid\">invalid\u003C\u002Fcode> can also mean the request needs something the oracle's language\ncannot express — a colour gradient in a figure, say. Rather than return an\napproximation that looks like an answer, the oracle declines at once and\n\u003Ccode>detail\u003C\u002Fcode> names what was missing. It is billed like any \u003Ccode class=\"chip chip--invalid\">invalid\u003C\u002Fcode>, and it is\nworth retrying: describe the figure without that feature.\u003C\u002Fp>\n\u003Ch2 id=\"error\">\u003Ccode class=\"chip chip--error\">error\u003C\u002Fcode>\u003C\u002Fh2>\n\u003Cp>Something on our side failed. \u003Ccode>credits\u003C\u002Fcode> is \u003Ccode>0\u003C\u002Fcode>, \u003Ccode>retryable\u003C\u002Fcode> is \u003Ccode>true\u003C\u002Fcode>, and\nnothing was charged.\u003C\u002Fp>\n\u003Cp>It still appears in your \u003Ca href=\"https:\u002F\u002Fapp.formalogic.io\u002Fusage\" target=\"_blank\" rel=\"noopener noreferrer\">usage log\u003C\u002Fa>, with \u003Ccode>0\u003C\u002Fcode> credits, because an outage\nyou cannot see afterwards is one you cannot hold us to.\u003C\u002Fp>\n\u003Cp>Note that \u003Ccode class=\"chip chip--error\">error\u003C\u002Fcode> arrives with HTTP \u003Cstrong>200\u003C\u002Fstrong>. The request was understood and\nprocessed; the oracle could not complete it. Branch on \u003Ccode>status\u003C\u002Fcode>, not on the\nstatus line — see \u003Ca href=\"\u002Ferrors\">Errors\u003C\u002Fa> for the failures that do change it.\u003C\u002Fp>\n\u003Ch2 id=\"in-one-table\">In one table\u003C\u002Fh2>\n\u003Cdiv class=\"doc-table\">\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>\u003Ccode>status\u003C\u002Fcode>\u003C\u002Fth>\n\u003Cth>\u003Ccode>result\u003C\u002Fcode>\u003C\u002Fth>\n\u003Cth>Billed\u003C\u002Fth>\n\u003Cth>Retry\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>\u003Ccode class=\"chip chip--valid\">valid\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>yes\u003C\u002Ftd>\n\u003Ctd>yes\u003C\u002Ftd>\n\u003Ctd>no need\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Ccode class=\"chip chip--invalid\">invalid\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>no\u003C\u002Ftd>\n\u003Ctd>yes\u003C\u002Ftd>\n\u003Ctd>only with a different intent\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Ccode class=\"chip chip--error\">error\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>no\u003C\u002Ftd>\n\u003Ctd>no\u003C\u002Ftd>\n\u003Ctd>yes, with backoff\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003C\u002Fdiv>\n\u003Ch2 id=\"why-not-a-score\">Why not a score\u003C\u002Fh2>\n\u003Cp>A confidence number would let a caller pick their own threshold, and every caller\nwould pick a different one — at which point the guarantee is theirs, not ours,\nand "verified" means nothing across two integrations. A verdict is a commitment.\u003C\u002Fp>\n\u003Cp>See \u003Ca href=\"\u002Fhandling-verdicts\">Handle every verdict\u003C\u002Fa> for what this looks like in\nclient code.\u003C\u002Fp>\n","# Verdicts\n\n> valid · invalid · error — what each means, which ones you pay for, and which are worth retrying.\n\nEvery answer carries a `status`. There are exactly three, and the difference\nbetween them is the difference between three different things you should do next.\n\n## `valid`\n\nThe answer passed the check.\n\n`result` holds the artifact. `verified_by` identifies the version of the rules that accepted it.\n**Billable.**\n\n`valid` is a statement about the artifact, not about the world: it passed its\nformat's checks. A chart's `data` says whether its values came from your request\n(`supplied`) or were illustrative values you allowed (`generated`).\n\n## `invalid`\n\nThe check refused the answer. There is no `result`; `reason` says why as a\ncode you can branch on, and `detail` says it in plain language:\n\n| `reason` | Meaning |\n|---|---|\n| `unsupported_feature` | The request needs something this oracle cannot draw |\n| `chart_type_mismatch` | The request names a kind of chart, and no chart of that kind passed in this format |\n| `no_valid_answer` | Nothing that passed could be produced for this request; say more concretely what it should contain |\n\n**Billable, and that is not a technicality.** The work was done, and a reliable\n\"no\" is the thing you are buying. An API that charged only for\nanswers it liked would have every incentive to loosen the rules until\neverything passed — which is precisely the failure mode a verdict exists to\nprevent.\n\nRetrying an identical intent may produce a different verdict, because the same\nintent can return a different artifact. Retrying it many times is a way to spend\ncredits.\n\nAn `invalid` can also mean the request needs something the oracle's language\ncannot express — a colour gradient in a figure, say. Rather than return an\napproximation that looks like an answer, the oracle declines at once and\n`detail` names what was missing. It is billed like any `invalid`, and it is\nworth retrying: describe the figure without that feature.\n\n## `error`\n\nSomething on our side failed. `credits` is `0`, `retryable` is `true`, and\nnothing was charged.\n\nIt still appears in your [usage log](https:\u002F\u002Fapp.formalogic.io\u002Fusage), with `0` credits, because an outage\nyou cannot see afterwards is one you cannot hold us to.\n\nNote that `error` arrives with HTTP **200**. The request was understood and\nprocessed; the oracle could not complete it. Branch on `status`, not on the\nstatus line — see [Errors](https:\u002F\u002Fdocs.formalogic.io\u002Ferrors) for the failures that do change it.\n\n## In one table\n\n| `status` | `result` | Billed | Retry |\n|---|---|---|---|\n| `valid` | yes | yes | no need |\n| `invalid` | no | yes | only with a different intent |\n| `error` | no | no | yes, with backoff |\n\n## Why not a score\n\nA confidence number would let a caller pick their own threshold, and every caller\nwould pick a different one — at which point the guarantee is theirs, not ours,\nand \"verified\" means nothing across two integrations. A verdict is a commitment.\n\nSee [Handle every verdict](https:\u002F\u002Fdocs.formalogic.io\u002Fhandling-verdicts) for what this looks like in\nclient code.\n",1793819974084]