Skip to main content
Each signal returns exactly {trusted, confidence} — no raw value. This is the part worth getting right.
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) carries an unresolved_reason telling you why:

​
Item outcomes

Each person in data[] carries a status that discriminates its shape:
Carries score, band, reason, and the signals map. This is the normal outcome.
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.
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, …).
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.