Cases

A metadata-safe caseload register. Each row contains only its opaque id, reference, lifecycle state, priority and opened/SLA/closed times. It never returns the title, narrative summary, subject/customer identity, names, outcome, assignee or actor ids. Those investigation details require `cases.case_content.read` on the case workspace.

The case subject is taken from the evidence rather than from the request body, so an analyst cannot open a case against the wrong customer by mistyping. Alerts lead when both kinds are present — an alert names an account and a transaction as well as a party — and a screening hit supplies the subject when there is no alert to take it from.

`alert_ids` and `screening_hit_ids` may name at most 200 records in total. Correlation groups are expanded before any write and the expanded combined set must remain within that boundary; overflow is a 422 and no case is created.

One response distinguishes the immutable evidence linked to this case from the wider history of the same subject. `alerts`, `screening_hits`, `attachments` and `transactions` remain linked filing provenance. Each linked collection is bounded at 200 with an explicit `truncated: true`/`service_cannot_resume` marker; it is never a silent partial array. The four broader subject collections (alerts, transactions, screening runs and screening hits) are independently keyset-resumable investigation context with independent read permissions and explicit coverage. Paging one collection never moves any other collection, and transaction cursors are valid only with the exact half-open window echoed by the response.

Linked `transactions` deliberately remains a bounded, explicitly truncated filing- provenance view. `subject_transaction_history` is the resumable traversal path for the subject's activity inside the selected window. Its database work is a bounded k-way account merge; customers with more than 200 accounts get `unavailable_account_limit` and no misleading partial activity.

A broader-history key is ABSENT when its permission is absent. When permission is present but the case has no usable subject/customer/account, the key is present with an `unavailable_*` or `available_no_accounts` coverage value. An empty `available` list therefore means the query really ran and found no rows; it never means "not allowed".

The queue snapshots its owning organisational unit onto the case. If an assignee is supplied they must currently be active, belong to that exact unit and hold at least one eligible role configured on the queue. Omitting the assignee leaves work owned by the queue without inventing an individual owner.

Encrypts the bytes and original filename under the case subject's DEK before writing to the configured write-once object store. The object key contains no case, person, filename or user data. Reusing the UUID `Idempotency-Key` for the same attachment is safe; reusing it for different bytes or metadata is refused.

Legacy `?filename=` query metadata is refused even when `X-Filename` is also present, because silently ignoring it would leave the sensitive value in upstream access logs.

Loads the tenant-scoped metadata first, decrypts the opaque object reference and bytes, verifies the stored plaintext SHA-256, and records both PII access and download audit events. The response is always an attachment with `no-store` and `nosniff` headers.

This does not close the case. It records a maker-checker proposal and moves the case to `pending_approval`; a different, role-authorised user approves it through `/v1/approvals/{approvalID}/approve`, and the closure is applied inside that approval's transaction.

The two-step flow is the control. Until Phase 2 the closer named their own approver in this request body, with no foreign key and no check that the named person had agreed to anything — the four-eyes rule was self-attested. The proposal payload is digest-bound, so editing the outcome after review invalidates the approval rather than riding on it.

Which roles may approve a case closure is `workflow.approvals` configuration, not code (BRD §7.2).

Notes are encrypted at rest under the subject's key and are append-only. An investigation record that can be edited afterwards is not evidence of anything.