Sanctions Desk

Sanctions Desk gathers and checks the evidence for every sanctions-screening alert and recommends an outcome; a person with the right entitlement approves it. One alert, start to finish · The problem it works on

Sanctions Desk / Architecture

Architecture

Six diagrams, each drawn from the code it shows (the sources are in the repository, rendered with Mermaid). Every label names a step, role or model as the code does.

How a review runs

The desk's agents read the bank's data only through Zetaris. The raw free text (notes, payment references, list remarks) is read by Nemotron 3.5 Lightning on the analyst's machine; the decision, critic and challenger send only structured facts to Nemotron 3 Ultra in the cloud (in every run with the screener; for the four early runs made before it existed, see earlier runs). A raise-only policy guard checks the result, and a person decides.

Architecture: the review desk, the desk agents reading through Zetaris, the safety guard and screener on local Lightning, the decision and critic on cloud Ultra, the policy guard, the person and the sealed record; flags, missing answers and cloud-served answers for raw text hold the case.
Source: docs/diagrams/1-architecture.mmd

One live review, step by step

The live review of alert ALR-0073: every Zetaris read and the role it ran under, every model call with the model that answered and its signed receipt, the critic's check, and the sealed record waiting for a person.

Sequence of the live review of ALR-0073: reads from Zetaris, two local Lightning calls, a cloud Ultra decision, the critic re-reading six facts and approving, the policy guard keeping the escalation, and the record waiting for a person.
Source: docs/diagrams/2-review-sequence.mmd

Every failure ends in a hold, never a close

Zetaris down, a data-quality failure or a cut-off list, a guard flag or no answer, an answer for raw text served from the cloud, a screener signal, a model that does not answer, a critic that does not approve, a credible challenge: each one holds or escalates the case. A block, or an override to a close, waits for a second approver.

Flowchart of the decision and its fail-closed paths, each failure leading to a hold or an escalation, and the four-eyes step for blocks and overrides to a close.
Source: docs/diagrams/3-fail-closed.mmd

The life of an alert

An alert is reviewed, its recommendation sealed, and a person decides; a block or an override to a close waits for a second approver. A change in a listed entry lists earlier decisions for a person, on request. Automatic closing exists but is off by default.

State diagram of an alert: new, under review, held, proposed, block pending, override pending, decided, automatically closed and reopened, and listed again after a list change.
Source: docs/diagrams/4-alert-lifecycle.mmd

Where customer data goes

Identifier numbers are masked as they are read. The raw free text goes only to the local model; every cloud prompt is checked for it before it is sent. The trace keeps ids and counts, the sealed record what an auditor needs, and receipts only the start of each prompt. Details: docs/PRIVACY.md.

Data flow: data from Zetaris masked on read, the raw text to the local guard and screener only, the check before every cloud call, the cloud prompt's fields, and what the trace, the sealed record and the receipts keep.
Source: docs/diagrams/5-data-privacy.mmd

Who may read what in Zetaris

Each review step that reads data has its own non-admin Zetaris role with only its tables; Zetaris itself refuses every other table and every write (85 of 85 checks).

Access matrix: each step mapped to its Zetaris role and the tables it is granted; every other table and every write refused.
Source: docs/diagrams/6-zetaris-access.mmd