Appearance
Running checks
Entity checks
The Checks section on the entity page has a dropdown of what can be run and a Run check button. Needs entity.review.refresh.
Running a check creates one EntityCheck and one ProviderFetchRun. It does not start or modify a review.
The dropdown is filtered by what the entity can support: IBAN verification appears only with an IBAN on file, domain intelligence only with a website.
Most checks run synchronously and the flash reports the outcome by name — Commercial registration refresh ran successfully or … ran but failed. See the check row for details. IBAN verification is asynchronous and reports has been queued.
Party checks
Run from a person's card under Relationships: Screen, Identity, Address, Digital ID, Employment, Other registrations. Needs entity.review.create.
Each button reflects the state of that check for that person:
| Shows | Means |
|---|---|
| The check name | Not run — click to run it |
| Retry … | The last run failed |
| A past-tense label | Completed |
| In progress | Running |
| Needs date of birth | Blocked — links to the person page |
Retrying
A failed check leaves a Retry failed checks item in Next steps with a Re-run button that carries the failed check's type.
A retry creates a new check record; the failed one stays as history. Intake posture reads only the most recent run of each type, so a successful retry clears the failure — the entity is not locked out by a transient provider error.
When a check cannot run
Verity refuses rather than sending a request it knows will fail. There are two kinds of refusal, and the difference decides what you can do about it.
Missing an input you can supply
The check is owed, and something has to be provided first. The button stays visible and says what is needed.
| Situation | What you see |
|---|---|
| No date of birth in the calendar the service matches on | Needs date of birth, linking to the person |
| Passport-only person, other-registrations check | Refused — Wathq needs a nationality code Verity does not hold |
| No IBAN | IBAN verification not offered |
| No website | Domain intelligence and website scan not offered |
| Person party required | Organization checks run at entity level; the card says so |
No provider in this country
The check can never run for this merchant, whatever you supply. The button is not shown at all, and the boundary is named once for the card:
Identity, Address, Digital ID, Employment, and Other registrations cannot run in Bahrain — no provider covers them there, so they are not offered.
A Bahraini party is offered one of the six party checks: sanctions screening, because a watchlist does not stop at a border. Elm does not operate in Bahrain, and Wathq is the Saudi registry.
Why this is not a disabled button
Before this, three of those five rendered as live buttons the resolver would refuse on click, and two said Needs date of birth — sending an operator to find a date that would change nothing, because there is no Elm in Bahrain at any date of birth.
The missing input was a true statement that misled. So the absent provider is reported instead, and it outranks any missing input.
Naming it matters: one chip on a Bahraini card and six on a Saudi one, with nothing saying why, reads as a permission problem.
Hiding the button is presentation, not the control. The request is refused on its own if it arrives anyway, and nothing is recorded — no provider call, and no failed check row, since "identity verification failed" is a claim about the person when the truth is that nobody looked.
After a check
- Verification coverage may move, if the check satisfied a scoring rule
- Gates may become evaluable — a gate that could not be read may now be clear or triggered
- Risk does not change on its own. Run Assess risk for that.
That last point is deliberate: the band carries a timestamp, so it should reflect a moment somebody chose, not drift silently as evidence arrives.