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

# Verdicts

> What comes back, and what to do with it.

## Status

```
pending → partially_captured → completed | expired | failed
```

`completed` means the verdict is in. `expired` means nobody finished the capture in time.

## Verdict

```json theme={null}
{
  "verdict": {
    "label": "suspicious",
    "score": 0.82,
    "reason_code": "screen_detected",
    "signals": {
      "screen_detection": { "screen_detected": true, "confidence": 0.94 },
      "ai_detection": { "label": "likely_human", "confidence": 0.88 }
    }
  }
}
```

| Field         | Meaning                                                                                                 |
| ------------- | ------------------------------------------------------------------------------------------------------- |
| `label`       | `verified`, `suspicious` or `failed`. **Branch on this.**                                               |
| `reason_code` | Why it isn't `verified`: `screen_detected`, `ai_generated`, `context_mismatch`, `reverse_search_match`. |
| `score`       | Confidence, 0 to 1. Show it; don't threshold it.                                                        |
| `signals`     | The evidence behind the label, one entry per check you asked for.                                       |

## Signals

Ask for them with `signals_required` when you create the verification.

| Signal    | Answers                               |
| --------- | ------------------------------------- |
| `screen`  | Is this a photo of a screen?          |
| `ai`      | Does this look AI-generated?          |
| `reverse` | Does this image already exist online? |

A photo that was uploaded from the gallery instead of captured live reports `{ "status": "not_applicable", "reason": "uploaded_content" }` on the checks that need a live camera. That is never a failure.

## Extra checks

Each one is switched on by a field at creation and comes back next to the verdict, never inside it.

| You send                                              | You get back                                                                       |
| ----------------------------------------------------- | ---------------------------------------------------------------------------------- |
| `expected_object: "car"`                              | `object_match: { status: "match" \| "mismatch" \| "inconclusive" }`                |
| `expected_location: "Av. Córdoba 5635, Buenos Aires"` | `location_match: { status: "verified" \| "no_match" \| "ungeocoded", distance_m }` |
| `condition_aspects: ["paint", "tires"]`               | `condition: { score: 7.8, label: "good", aspects: [...] }`                         |

Set `expected_object` or `condition_aspects` on an `image` step instead of the whole verification and the result comes back per step: `object_matches.<key>` and `condition.steps.<key>`, with the overall `object_match` and `condition` summarizing them.

## Live capture vs audit

A **verification** is a photo taken live, right now, through the link or an SDK. Its verdict is backed by the device.

An **audit** (`"mode": "audit"`) analyses a photo you already have. Same response shape, but no device stood behind it: read the label as a strong signal, not as proof. Audit uploads go through the SDKs, which are available by request — write to [ulises@rial.io](mailto:ulises@rial.io?subject=Audit%20access).