Investigation and casework
One subject, one chain of provenance, two pairs of eyes
A case is the workspace where an alert becomes a decision. It holds the evidence that decision follows, separately and visibly from the broader history an investigator reads to understand it — and it cannot be closed by the person who proposed the outcome.
Everything on the case screen is scoped to one canonical subject. A case whose party and customer pointers identify different people fails closed rather than combining both identities, and a case with no subject never falls back to a tenant-wide query.
The problem
Investigation quality is destroyed by two specific confusions
Both look like helpfulness at the time. Both produce a filing that cannot be defended, and neither is visible on a screen that has flattened them.
Context that became evidence by accident
An investigator pulls the subject's wider transaction history to understand a pattern. In a system that shows one undifferentiated list, that context is indistinguishable from the activity actually attached to the case — and the narrative ends up describing transactions the filing has no provenance for.Two subjects in one case
Correlating alerts across related parties is useful right up to the point where a case combines evidence about two different people. The report that follows names one of them, and the other one's activity is in the totals.A closure nobody independently agreed
Where the investigator who worked the case also closes it, the four-eyes control exists in the policy document and nowhere else. The audit trail records one name, and the institution has no evidence that a second person ever looked.
The core design decision
Linked evidence and subject history are kept visibly apart
The case workspace keeps two different questions separate on the screen, because they answer to different standards. One is the provenance a filing or a closure follows. The other is the context an investigator needs in order to think.
Analyst
A case opens from the alert that justified it
Escalating from an alert opens a case with a title and a summary, attaches that alert as evidence and takes the investigator straight into the workspace. Every piece of selected evidence must resolve to exactly one subject party; evidence that does not is refused rather than quietly widening the case.Platform
Linked transactions are resolved, not retyped
The workspace resolves every transaction reachable through the case’s alerts, deduplicates them by their immutable identity and sorts them newest first. The bound is visible rather than silent: the screen reports how many alerts it evaluated, how many it drew from, and whether the set was truncated. Each transaction carries its counterparty-screening disposition, and a transaction that predates durable screening linkage says so — it never reports an invented zero.Analyst
Read the wider history without absorbing it
Subject alert history, customer transaction history across every account, and screening history — runs as well as dispositions — are each cursor-paginated independently and each state their own coverage. The transaction window is half-open and echoed back exactly, so a reader knows precisely which period the screen is describing and can step back a year at a time without any other control on the page moving.Analyst
Attach evidence that cannot be altered afterwards
Attachments are encrypted under the subject key before they cross into write-once storage. The object key carries only tenant and attachment identifiers — case identifiers, party identifiers, usernames and filenames never enter the object namespace — and the filename itself is encrypted metadata. Every download re-authenticates the object, verifies the recorded digest, writes a sensitive-access record and returns no-store headers. Investigation notes are encrypted and append-only, because a note that can be edited afterwards is not evidence.Compliance administrator
Routing is configuration, and transfers are deliberate
A queue owns one organisational unit and a set of eligible roles, and a priority maps to at most one active queue — so opening a case has a deterministic automatic route, and no configured mapping produces an explicitly unqueued case rather than a hidden fallback. An individual assignee is accepted only when they are active, belong to that exact unit and hold at least one eligible role. Moving a priority between queues is two explicit steps; a conflicting write is refused rather than silently rewriting another queue’s configuration. Queues are retired, never deleted, and every existing case keeps its assignment snapshot.Analyst or MLRO
Closure is proposed, and someone else agrees it
A closure proposal names an outcome from a closed list — false positive, no suspicion with the activity explained, a suspicious transaction report filed, a currency transaction report filed, escalation to an external authority, or the relationship terminated — with a rationale written for the reviewer. The proposer cannot approve it. The resulting case status is derived from the outcome on the server, so a case can never read “closed, no action” while its outcome says a report was filed.Platform
The timeline is the record, and it is append-only
Opening, automatic routing, assignment, evidence upload and download, note entry, closure proposal and approval are appended in causal order, and every one of them also extends the tenant audit chain. Closure state, actors and timestamps are write-once after the terminal transition.
In the product
The case workspace
Sections, not tabs. A panel that unmounts when you look away loses a half-written investigation note, and “did you review every linked alert” is a question a screen that hides three quarters of itself answers badly.
Placeholder — TODO: capture the case workspace screen (/cases/{id}) from a seeded demonstration tenant — no screenshot of it exists yet. Replace with sourced, approved content before this page is made public.
/cases/{id}case workspace
Screenshot slot. Capture from a seeded demonstration tenant with synthetic data and replace this frame. Do not substitute a mock-up of the interface.
What the capture must show
- Case-linked alerts and transactionsThe provenance set, with its evaluated-alert counts and truncation state visible rather than implied.
- Screening evidence, with undecided flaggedAttached hits strongest first, and a warning when any are still undecided — closing over an undecided sanctions match is a decision the platform will not quietly allow.
- Broader subject historySeparately headed, separately paginated, and carrying an explicit coverage statement rather than an empty list that could mean either nothing happened or nothing was queried.
- Assignment panelQueue ownership shown separately from the individual investigator, with only currently eligible assignees offered.
- Subject panelRisk rating and score, KYC tier, an enhanced due-diligence notice where one applies, and the top contributing risk factors.
- Closure proposalOutcome, rationale, and a plain statement that this sends the case to a second reviewer rather than closing it.
Controls
What makes a case defensible
These are the properties that survive the case being read by someone who was not there.
One canonical subject, resolved not guessed
The subject is resolved through the customer relationship where one exists. Where a case's party and customer pointers disagree the read fails closed instead of combining both identities, and a case with no subject never falls back to a tenant-wide query.Evidence read is a separate right from case read
Seeing that a case exists and seeing what is in it are different permissions. That is what stops executive-level case visibility from silently exposing counterparty names, account references and investigator uploads.Four-eyes closure, enforced below the application
The proposer cannot approve. Which roles may approve a closure is configuration rather than code, and the constraint that makes the pairing hold is enforced in the database rather than in the screen that renders the button.Assignment is validated at the moment it is made
An assignee must be active, belong to the queue's exact organisational unit and currently hold an eligible role. A retired queue stops receiving automatic routes while every existing case retains its snapshot and its timeline.Bounds are stated, not silently applied
Linked evidence, subject history and account coverage are all capped, and every cap is reported with the counts behind it. Where the evidence volume exceeds what a synchronous workspace can bound, the platform refuses the operation rather than returning a subset that looks complete.A filing is derived from the case, not retyped from it
A draft report is assembled from the linked evidence with a narrative that defaults to the case summary. Figures come from the evidence set rather than from an investigator re-entering them, which is where transcription errors enter a regulatory return.
Where the edges are
What the case workspace will not do
Mostly these are refusals rather than gaps, and they are refusals on purpose.
In the product today
- Case creation from one or more alerts, subject-consistent evidence linkage, deduplicated transaction resolution and counterparty-screening disposition per transaction.
- Encrypted, write-once attachments with digest-verified, audited download, and encrypted append-only investigation notes.
- Independently paginated subject alert, transaction and screening history with explicit coverage states rather than empty lists.
- Routing queues by priority, organisational unit and eligible role, with validated assignment and retirement instead of deletion.
- Four-eyes closure over a closed outcome vocabulary, with the case status derived from the outcome, and an append-only timeline extending the tenant audit chain.
Not claimed here
- Cases spanning several subjects. This is a refusal, not a missing feature: evidence that does not resolve to exactly one subject party is rejected, because a filing assembled across two people names the wrong one.
- Deleting a case, a queue or an attachment. Write-once evidence changes deletion semantics — a case or a tenant holding retained evidence cannot be deleted, cases are closed and queues are retired.
- Synchronous filing generation from an unbounded evidence set. Beyond the bound the workspace refuses rather than producing a partial return, and states that the installation has no supported complete filing path at that evidence volume.
- A guaranteed archival or write-once certification. The filesystem and S3 adapters are storage mechanisms; bucket retention, object lock, encryption and access policy are infrastructure controls the operator configures for their regulatory posture.
Keep reading
Related capabilities
Where the evidence comes from, where the decision goes, and how both are retained.
Walk a real investigation
From alert to closure proposal in one session
We will escalate a seeded alert, attach evidence, read the subject history beside it, draft a filing from what is linked, and propose a closure that a second account has to approve.