The person workspace

/people/:id — everything Verity knows about one human across the whole account.

Why it exists

People are resolved and deduplicated by identifier, so the same individual on six merchants is one record. That is what makes portfolio linkage possible — and what makes this page useful: it answers "where else does this person appear?", which no single entity page can.

Checks on this person

The first thing on the page: every person-scoped check, what it says, and — where it says nothing — why. Each row is one of six states, and only one of them is reassuring:

State	Means
Verified / No matches	The provider answered, and the answer was clean
A finding	The provider raised something. A match is not a finding until somebody adjudicates it
Unresolved	The check ran but the answer is not final — the provider or a human still owes one
Could not be read	An attempt was made and failed. Nothing was learnt
Cannot run	No attempt is possible, and the missing input is named
Not checked	Nobody has looked

Not assessed is not clear

The checks that could not be read are grouped underneath by the one cause they share, under the same words the entity page uses: not assessed is not the same as clear. A person with no checks run reads as an empty file, never as a clean one.

Whether a check ran is review information, so this readout is visible to anyone who can see the person. What the provider said when a run failed needs provider_fetch_run.view — that is raw provider traffic.

Identity

What the file holds beside what the government record returned, field by field, in one table. Elm's own status decides whether they agree; the rows are there so a human can compare names across transliteration and dates across calendars — comparisons a string test would get wrong in both directions.

Where no usable date of birth is on file and you have entity.update, a field appears to record one. It is stored as declared, not verified and labelled that way everywhere — see People and calendars.

A date in the wrong calendar is not a date

Yakeen matches citizens on Hijri and Iqama holders on Gregorian. A date stored in the other calendar cannot be used, and the page says exactly that rather than reporting the field as empty — showing the value, so whoever corrects it can see what is there. Reporting it as missing sends an operator to retype the date already in the field.

Aliases and provider keys are folded away under How this record was matched: they explain how the record was joined, not what it says.

Where this person appears

Every entity in the account carrying this person, with the relationship, whether it is current, and the entity's live review. The fastest route between related merchants.

Screening findings

What the screening provider asserted about this person: classifications such as PEP or government office, watchlist source, and provider notes.

Evidence, not truth

The panel is labelled evidence for a decision, not canonical truth. A provider calling someone a PEP is that provider's claim, sourced from a named list, and it is presented as such rather than as a fact Verity has established.

Bar from future acceptance

Barring a person is the bar that actually stops a return. They appear on many entities, so barring a single merchant leaves the operator free to open another next week; barring the person blocks approval of every merchant they are attached to, now and later.

Needs denylist.manage. If a bar is already in force, the page says so at the top instead and names the source and reason.

See Standing bars.

Registered address

The addresses the national address register returned — the rows themselves, not just how many. An explicit statement when the check has not run.

Check history

Last, and folded away. Every provider run attempted for this person including the ones that failed, each linking to its fetch run. It is the plumbing behind the verdicts at the top of the page rather than something you read to understand the file. Needs provider_fetch_run.view.