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

# The verdict model

> Each signal returns {trusted, confidence}. Why null is first-class and never means false.

Each signal returns exactly `{trusted, confidence}` — no raw `value`. This is the part worth
getting right.

| Value | Means |
| - | - |
| `trusted: true` | Confirmed. The number connects, or the name or profile matches. |
| `trusted: false` | Confirmed otherwise. A positive finding, **not** an absence of one. |
| `trusted: null` | Unconfirmable — no source could answer. Never read this as `false`. |
| `confidence` | How strongly the sources agreed, 0–100. Always present; carries `null` exactly when `trusted` is `null`. |

> [!WARNING]
>
> `false` means we checked and the answer was no. `null` means nobody could tell you. Treating
> the second as the first is how a good lead gets discarded.

## The invariant

`confidence` is `null` **exactly** when `trusted` is `null`:

* A resolved verdict is a boolean `trusted` with an integer `confidence` (0–100).
  `{trusted: false, confidence: 100}` is a certain negative.
* An unresolved verdict is `{trusted: null, confidence: null}`.

A mixed `{trusted: null, confidence: 100}` or `{trusted: true, confidence: null}` is **not a
valid verdict** — the two fields move together. A signal that could not run is always
`{trusted: null, confidence: null}`, never `{trusted: false}` and never a bare confidence with
no verdict.

## Why a verdict was unresolved

When a verdict is `null`, an unresolved item (see [below](#unresolved-items)) carries an
`unresolved_reason` telling you why:

| `unresolved_reason` | Means |
| - | - |
| `inconclusive` | A source ran or answered but could not conclude on this input. |
| `source_unavailable` | A source could not be reached — a transient outage. Worth a retry. |
| `no_coverage` | No source covers this input, so none was consulted. |

## Item outcomes

Each person in `data[]` carries a `status` that discriminates its shape:

> **scored — a verdict was produced**
>
> Carries `score`, `band`, `reason`, and the `signals` map. This is the normal outcome.

> **unresolved — it ran, but nothing could be scored**
>
> Every signal you asked for returned `trusted: null`, so there is nothing to score. It
> carries **no** `score`, `band`, or item-level `reason`, but — unlike a rejected item — it
> **returns its full `signals` map**, each null verdict with an `unresolved_reason`.

> **rejected — the input could not be used**
>
> A normal outcome for that row, not a failed request. The batch still returns and other
> items still carry verdicts. The `reason` appears on the item (`no_runnable_signal`,
> `invalid_phone`, …).

> **error — the item failed**
>
> May carry a `reason` when it is known, but an errored item is promised no field beyond its
> `status`. A per-signal vendor outage degrades that signal to `null` — it never fails the
> whole batch.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.