Design walkthrough
How Transit Risk Decision Integrity works.
This is a synthetic demonstrator. It shows how a transit risk alert can become an authorised intervention with attributable evidence, structured outcomes and KATLAS-signed receipts — without centralising customs or trader data and without replacing existing systems.
Nine steps
From anomaly signal to attributable outcome.
- 01
Fragmented customs and transit estate
Declarations, manifests, border events and trade documents sit across multiple services. A catalogue may describe what exists, but it does not by itself govern what may happen next.
- 02
Movement event or declaration arrives
A transit movement, declaration or manifest event enters the estate from a partner service. Source services retain custody; only references travel.
- 03
Analytics or rules engine identifies anomaly
A partner analytics or rules engine flags an elevated risk signal — document mismatch, route deviation, seal contradiction, documentary gap or multi-signal corroboration.
- 04
KATLAS opens a governed Risk Decision Case
A Risk Decision Case is created with the anomaly summary, source service, rule/model version, confidence band and data-quality caveats attached.
- 05
Evidence provenance and caveats are assembled
Supporting and contradictory evidence references are assembled with custodian and provenance markers. Withheld evidence is counted but not exposed.
- 06
Correct authorised role receives action request
The action request is routed by role: case officer, border officer, rule owner or supervisor. Each role only sees actions it is authorised to take.
- 07
Hold / inspect / clarify / release / escalate
The authorised officer records the intervention. Each action captures actor, role, rationale, evidence sufficiency note and policy basis.
- 08
KATLAS issues a receipt
KATLAS signs a receipt for each material intervention: alert created, action requested, inspection performed, hold applied, clarification requested, release issued, escalation raised or case closed.
- 09
Outcome returns to learning loop
Confirmed non-compliance, false positives, intelligence gaps and rule-refinement signals are recorded so the rules and operations improve over time.
Architecture comparison
Centralised risk platform vs federated operating view.
Centralised risk platform
A single database.
- pushes for full data pooling across services
- obscures local custody and accountability
- can blur action authority across teams
- can make justification retrospective
- creates another single point of failure
Federated operating view
A shared view, not a shared store.
- movement data stays under source custody
- evidence references travel, not raw data
- authority is explicit at decision time
- receipts make interventions reviewable
- outcomes feed back to rules and operations
For advisory audiences
Design ideas this demonstrator is intended to inform.
- 01
Intervention integrity, not just risk score: a high risk score does not authorise an action.
- 02
Evidence provenance must travel with the alert — including what is withheld and why.
- 03
Policy-bound action: every intervention names the policy, rule version and authorised role.
- 04
Feedback for rule refinement: false positives and confirmed non-compliance return to the rules service.
- 05
Federated governance can sit alongside existing customs and border systems, not on top of them.
- 06
Operational truth is reviewable through receipts, without exposing trader or cargo data.
Synthetic, non-procurement disclaimer
This is a synthetic demonstrator, not a replacement for CDS, NCTS, GVMS or Border Force operational systems. The purpose is to show how a risk alert can become a governed intervention with clear authority, attributable evidence and structured learning. KATLAS provides the decision-integrity layer between risk analytics and operational action.
Follow it end-to-end
The control room applies this nine-step pattern to five synthetic transit cases. Open one to see the evidence boundary, the authority gate, the recommended actions and the KATLAS receipt status.