Appearance
Reading evidence
Every check links to its provider fetch run — the actual call. This is where you go when a result looks wrong, surprising, or too good.
Needs provider_fetch_run.view.
What a fetch run shows
Run summary — provider, fetch type, lookup identifier, status, when it ran.
Normalised evidence — the fields Verity extracted, labelled and rendered as first-class content. This is what the rest of the product reads.
Raw response — exactly what the provider returned, unmodified. When normalisation and your expectation disagree, this settles it.
Request and response snapshots — the HTTP method, URL, headers, status and body, with credentials filtered ([FILTERED]). For failures this includes the provider's own error body, which is usually the fastest way to understand a failure.
Failures leave a record
A failed provider call still creates a fetch run, with the error captured. A failure that vanished without trace would be the one outcome an audit trail exists to prevent.
Every provider client's errors are caught by a common handler, so a provider added later is covered without anyone remembering to extend a list.
"No normalized evidence is available yet"
This means the structured extraction produced nothing to render. Three possible causes, and the page says so rather than implying the check found nothing:
- The provider genuinely returned nothing
- Normalisation did not complete
- This fetch type stores little structured data
The raw payload below is still there in every case.
Reading results honestly
Two habits worth keeping:
A missing count is not zero. A pending screening has no match_count. Zero means we looked.
A verified flag needs a positive signal. Verity requires providers to affirmatively say a check passed, rather than inferring it from the absence of an error — an empty body or a truncated response must not read as verification.
The person workspace
A person's page opens with Checks on this person — what each check says, and where it says nothing, why — then the identity comparison, which entities they appear on, and the provider evidence underneath.
Screening findings there are labelled evidence for a decision, not canonical truth. A provider calling someone a PEP is that provider's assertion, and it is presented as such.
Whether a check ran is review information and is visible to anyone who can see the person, on the same footing as the party chips on an entity page. What the provider said when a run failed needs provider_fetch_run.view — that is raw provider traffic.