Manual review

Everything the pipeline is unsure about lands here. A fast, honest review process is not overhead — it’s the mechanism that lets the automated thresholds stay strict without stranding legitimate users.

Working the queue

# List (oldest first — work in order)
GET /v1/review/queue
Authorization: Bearer <API_KEY>

# Decide
POST /v1/review/{verification_id}
{ "decision": "approve", "note": "MRZ glare only; fields match doc; face clearly same person" }

The note is mandatory and lands in the audit chain — write it for the future reader (a regulator, a dispute, next month’s you). Decisions fire the same webhook as pipeline decisions, so your products need no special handling.

Reviewer guidance

For each queued verification you have: the decision_reasons (why it’s here), the extracted fields, and — via operator vault access — the actual artifacts.

It’s here because…	Check	Lean
Quality issues / low confidence	Can you read every field? Does everything match?	Approve if clearly legible and consistent; otherwise reject and let the user re-try with better capture
Tamper signal	Look at the specific region the signal names — photo edges, font runs, MRZ vs printed text	Treat seriously: false positives happen (glare, worn laminate), but confirmagainst the named evidence, don’t dismiss
MRZ check-digit failure	Compare MRZ characters against the printed zone — misread 0/O, 1/I are common OCR causes	If the printed data self-checks and matches the visual zone: capture problem. If the document really carries invalid checksums: reject — genuine documents don’t
Liveness not confirmed / biometric unavailable	Compare selfie frames to the portrait yourself; check the frames actually show the poses	No liveness evidence at all → reject rather than approve on a single static selfie
identity changed between frames	Look at all frames side by side	This is the strongest fraud signal in the system — reject unless it’s an obvious artifact (e.g. second face in background), and flag per incident response
Pipeline error	Read the error; the artifacts are intact	Re-examine manually; file the error as a bug

Feed the loop

Every review is training data for the thresholds:

• Approving a lot of one signal type → that check is too strict; tune it.
• Catching things the pipeline scored clean → file a hardening-roadmap entry with the example.

Track your overturn rate — it’s the single best measure of threshold health (Monitoring).

Review SLA

Set one and alert on it (time-in-review metric). Users stuck in review are users churning; a queue nobody works converts fail-safe design into fail-stuck reality. Hours, not days.