The manual review queue, one of the few things on this list we actually ship
This is running code, not a roadmap item, which makes it unusual on a page list where most entries are things we have declined to build.
What a review queue is
The holding area a verification system routes cases to when it cannot resolve them automatically: a document that scanned oddly, a liveness check that came back borderline, a name that fuzzy-matched a list, a session that expired mid-flow. A human then makes a binding call, approve, reject, escalate, or ask for more information: that the automated system was not trusted to make alone.
Nobody invented this shape. FATF's risk-based-approach guidance is why an escalation path has to exist at all; the queue itself, priority ordering, assignment, a fixed decision set, an audit trail, is ordinary case-management practice borrowed from fraud and support operations. Solidus originated no part of it.
What Solidus ships, precisely
There are two queues in the codebase, and conflating them would overstate what the dashboard does.
The dashboard queue is a computed view over failed and expired verifications. It orders cases with a transparent, non-ML heuristic: a base value set by the failure reason, plus a fixed increment for each prior failure by the same subject, capped. A reviewer can approve, reject, escalate, or request more information; approve overturns the automatic rejection and issues the credential; either way a row is written to the audit log.
Two things about it we would rather state than have discovered:
- There is no assignment model. The field is a hardcoded null. Every open case reads as unassigned because there is no team concept behind it yet.
- The audit row names the surface, not the person. The actor recorded is the dashboard itself. It tells you a decision was made and what it was; it does not tell an auditor who made it.
The second queue, a separate API over a real cases table, is where the separation-of-duties control lives, and it is stricter:
- Where a case is opened requiring four eyes, the second disposition must come from a different user holding an approver role. The role is re-read from the membership table inside the transaction, not taken from the session token, which can go stale after a role change, and it is not enforced only in the interface.
- A reason is mandatory. A whitespace-only reason is rejected outright. A disposition an auditor cannot read is worth nothing.
- The case update, the decision record and the audit row share one transaction. A disposition that could not be audited does not commit.
- A session with no per-user identity cannot dispose of a case at all: an API key or a legacy account-level session is refused, because separation of duties is meaningless without distinguishable actors.
Cases are opened with four eyes required by the decisioning pipeline on high-risk and error outcomes, by the screening module, and by the document review gate.
The bounds, and they are real
It handles our pipeline's uncertain outcomes, not your compliance workload. This is Solidus
Verify deciding what to do about its own failed verifications. It is not a bank's or an
exchange's AML case-management system, and we do not build one. Sanctions screening, adverse-media
and PEP handling are not-built, so the cases that dominate a real compliance queue never arrive
in ours.
The ordering heuristic is not a risk score in the regulatory sense. It is a transparent arithmetic ordering derived from failure reasons and repeat failures. Treating it as an AML risk rating would be a misuse of it, and we would rather say so on this page than have it inferred from the word "risk" in an interface.
No customer has run volume through it. It is real code against a real database, exercised in testing, not a system that has met a production caseload.
And a stranger cannot check this one. Everything above sits behind dashboard authentication; there is no public URL you can fetch to confirm it. Elsewhere on this site we point at something you can verify yourself. Here we cannot, so we are telling you rather than implying evidence we cannot produce.
What reuse actually removes from a queue
A credential that has already been issued and is presented again does not re-enter this queue, because the queue is fed by verification outcomes, not by presentations. That is the honest version of the reuse argument: the review load that reuse removes is onboarding review at the second relying party, conditional on that party accepting a credential someone else issued.
It does not discharge that party's own obligation. A business required to perform its own customer due diligence keeps its own queue regardless of what we do, and whether a third-party credential satisfies that duty is unsettled, see re-KYC and remediation. Reuse is a cost and friction argument. It has never been a compliance transfer.
Why there is no number here
The obvious metrics, queue depth, time to decision, overdue rate, how many cases an upstream false-positive rate generates, all require production volume to mean anything, and we have none. We could publish figures from our own test traffic; they would describe our tests, not your caseload. We are not publishing them, and if a Solidus page ever shows a queue or review-time figure, it is wrong.