> ## Documentation Index
> Fetch the complete documentation index at: https://docs-attestly.code4source.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Verdicts

> How check outcomes compose into a status + outcome.

Every `/v1/evaluate` response carries **two top-level enums** on
purpose:

| Field     | Values                                              | Meaning                            |
| --------- | --------------------------------------------------- | ---------------------------------- |
| `status`  | `ok`, `degraded`                                    | Did the evaluation finish cleanly? |
| `outcome` | `compliant`, `warning`, `non_compliant`, `degraded` | Did the policy pass?               |

You read both. `status: ok` + `outcome: non_compliant` is a clean
evaluation that found a policy violation — block. `status: degraded`
means at least one referenced source has **no data in our store** —
treat with caution and consider retrying.

`status` is driven exclusively by whether each referenced source has
ever been ingested (we check `dataset_references[].collected_at_latest`
internally). A transient upstream failure during a single request does
not flip `status` to `degraded` as long as we have prior data for the
source — you'll see `dataset_references[].collected_at_latest` carrying
the older timestamp, and it's your call whether that data is fresh
enough for your use case.

> **"No intersections in the queried area" is NOT degraded.** A
> source with rows in our store but zero overlapping your input geometry
> stays `status: ok` and the relevant check returns zero hits. Degraded
> only signals "we have nothing at all for this source".

## Outcome semantics

| Outcome         | Meaning                                                                  |
| --------------- | ------------------------------------------------------------------------ |
| `compliant`     | All checks passed. Safe to proceed.                                      |
| `warning`       | At least one warning-severity check triggered. Review before proceeding. |
| `non_compliant` | At least one error-severity check triggered. Block.                      |
| `degraded`      | Result is incomplete; some checks could not be evaluated.                |

## Severity

Each check declares one of five severities — `critical`, `high`,
`medium`, `low`, `info`. The default policy maps them to outcomes
roughly like this:

* `critical` / `high` → triggering pushes the outcome to `non_compliant`.
* `medium` / `low` → triggering pushes the outcome to `warning` (if
  not already `non_compliant`).
* `info` → never affects outcome; surfaces as a triggered check for
  reporting.

Rulesets can also declare an explicit `verdict_policy` to override the
default mapping. See the [authoring guide](/authoring/ruleset-basics).

## Evidence

Each triggered check carries up to 20 matching features in
`evidence[]` — the actual items that caused the check to fire. Use
them to render explanations to your users ("polygon overlaps the
*Yanomami Indigenous Territory* by 0.42 km²") instead of opaque
pass/fail flags.

Each check also reports `total_matched` — when this exceeds
`evidence.length`, the UI should indicate truncation.