Manual Review

A type can require a person to confirm the outcome before it is accepted. That is a real control and a real commitment.

Where to find it

Architect Panel → Security:

User Verification — the console — providers, types, checks and their history

Architect Panel → Security:

Permissions — the group awarded once a review passes

When it is worth it

The verification grants access to something genuinely sensitive.
The provider returns results you sometimes need to interpret rather than accept.
A regulatory obligation requires a named person to be satisfied.
Volumes are low enough that reviewing everything is realistic.

When it is not

High volume with low consequence. A review that must happen for thousands of users becomes a rubber stamp, and a rubber stamp is worse than no review — it produces a record asserting that somebody checked, which nobody meaningfully did.

If you cannot review properly, do not claim to.

An unworked queue is a queue of people

This is the failure mode to design against. Every item waiting is a user who cannot do what they came to do, and who has no way of knowing whether anything is happening.

Before enabling manual review, decide who works the queue, how often, and what the target turnaround is. Then check it is actually happening a fortnight later.

What a reviewer should look at

The provider's outcome and evidence summary.
Any recorded failure reason.
The event history — a check with an odd sequence deserves more attention than its final status suggests.
Whether the type is appropriate for what the user is asking for.

Reject with a reason

A rejection with no explanation produces an immediate re-attempt, usually identical. Saying what was wrong is what lets somebody succeed on the second try, and it is what makes the decision reviewable later.

Do not reduce checks to speed the queue

The temptation when a queue builds is to look at less. If the queue is too big to review properly, the answer is more reviewers or fewer things requiring review — not a shallower review.

Watch the turnaround, not the depth

Track how long items wait. A queue that is always short is working; one that grows through the week and is cleared on Fridays is one where users wait days without knowing it.

Worked example

An organisation requires manual review only on the type granting access to clinical records — around fifteen a week. Two named reviewers work it daily with a one-working-day target. Ordinary affiliation checks are automatic, so the reviewers see the fifteen that matter rather than several hundred that do not.

Recommendations

Require review only where consequence is high and volume is low.
Name who works the queue before enabling it.
Always give a reason when rejecting.
Track waiting time as the health measure.