> For the complete documentation index, see [llms.txt](https://docs.goassay.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.goassay.ai/developers/under-the-hood/verification.md). # How calls are verified Understand result checks, verdicts and their effect on charging and provider quality. Assay checks the response against the tool's promises after mapping the provider's data into the tool's output shape. The receipt tells you which checks ran and what decided the call. A successful provider request alone does not establish that its data passed these checks. ## What gets checked Request authentication and result verification answer different questions. The provider's [request verifier](/developers/list-your-api-get-started/verify-in-your-code.md) establishes who sent the request. Assay's result checks decide whether the returned data meets the configured policy. | Check | What it can establish | Current behavior | | --------------------- | -------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | Response shape | Required fields, types and other declared output-schema constraints. A schema is a description of the expected JSON shape. | Checked at the response-mapping boundary and by the configured schema stage. No declared schema means that stage does not apply. | | Quality rules | Minimum result count, required values, freshness, numeric ranges, valid URLs and no duplicates. | The configured rules judge the mapped response. Conditions can limit when a rule applies. | | Meaning and relevance | Whether the answer fits the request and the tool's scope. | Runs when configured and selected for sampling. The receipt distinguishes a skipped sample from an unavailable check. | A receipt lists every check that ran for the call; a check that did not run is never shown as passed. For calls with a verification policy, the schema and quality-rule stages are unsampled. An absent policy can still result in a charged call recorded as `UNVERIFIED`. Read the actual check rows; do not infer “all checks passed” from a charge. ## How a decision is made A quality rule can pass, fail, not apply, or be pointed at data it cannot judge. For example, a numeric range rule pointed at a string can mean the policy is wrong. Assay records that as a misapplied check rather than blaming the provider. The quality-rule score is the passed rule weight divided by the weight of rules that applied. The stage compares that score with the policy's pass threshold. A rule excluded by its condition contributes no weight. Empty results have a separate policy: an honest empty answer is not automatically a failure. A versioned decision policy combines the declared checks. Its ordered clauses can require a count or fraction of failures, give a named check a veto, or specify what to do when too few checks ran. The first matching clause decides the verdict. An unavailable or inapplicable check supplies no pass or fail vote. Only checks declared in the policy count. ## What the verdict means The effects below apply to an active, enforcing policy. “Settle” means the call may be charged and proceed to payment collection; it does not mean the provider already has the money. | Verdict | Meaning | Payment decision | Provider strike | | ------------------ | ------------------------------------------------------------------------------- | ----------------------------------- | --------------- | | `PASS` | Met the policy. | Settle. | No | | `FAIL` | Evidence shows the provider broke the tool contract. | Refund the reservation. | Yes | | `EMPTY_CONFIRMED` | Empty is corroborated as the right answer. | Settle. | No | | `EMPTY_UNVERIFIED` | Empty answer without independent corroboration. | Settle. | No | | `MISAPPLIED` | The check did not fit the response or request. | Void; no charge or provider credit. | No | | `DEGRADED` | A needed check was unavailable after other checks, or the policy was withdrawn. | Settle. | No | | `SKIPPED` | The sampled check was not selected. | Settle. | No | `UNVERIFIED` is a separate record for a call with no decision policy. It settles without claiming a verification pass. Policies being evaluated in shadow mode do not refund or strike based on their verdicts; withdrawn policies also cannot penalize providers. ## How this affects the failure rate Only `PASS` and `FAIL` contribute to the provider's measured quality window. The observed failure rate is: ``` FAIL calls / (PASS calls + FAIL calls) ``` No observations means no measured rate. Request and system errors are tracked separately from data-quality failure. A `FAIL` records a strike, but a penalty against stake depends on the provider's quality window, sample gate and declared failure rate. That calculation and the on-chain proposal are separate from refunding the individual call. See [Staking and penalties on chain](/developers/list-your-api-advanced/staking-and-penalties.md). ## Example: read a result honestly A receipt can show a schema pass and a rules pass while the meaning check was not sampled. That describes the evidence available for this call. It does not establish a relevance judgment. If the result is bad despite those checks, use the call's report action and filing deadline. ## Go further * [Map your API to a tool contract](/developers/list-your-api-advanced/map-your-api.md) * [Dispute a stake penalty on chain](/developers/list-your-api-advanced/dispute-a-stake-penalty.md) ## Next * [Settlement and the hold window](/developers/under-the-hood/settlement.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.goassay.ai/developers/under-the-hood/verification.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.