Security & compliance
Builds on — Record · Access
Adjudication is a regulated activity: decisions must be traceable, records retained and protected, access controlled, and process rules followed as they change. The platform provides the mechanisms an operator relies on to meet those obligations. This page is the map; each mechanism is enforced in a capability documented in full elsewhere — most of it composes Record and Access.
Compliance touchpoints
The obligations a regulated operation meets and the platform mechanism that holds each one:
| Concern | Where it’s enforced | What the operator shows on review |
|---|---|---|
| Customer isolation — one tenant’s data stays sealed from another’s | The tenant boundary in Record — a per-deployment account with its own datastore, object storage, and identity realm | The deployment account itself; the absence of any cross-account credential or network route |
| Case isolation — one case’s data stays sealed from another’s within a tenant | The case boundary in Record — the data path is shaped so a cross-case read can’t be expressed; storage credentials are scoped per case | The query layer’s required-case parameter; the per-case storage policy |
| Immutable audit trail — every action is recorded and the record can’t be edited | The append-only event history — one store for the case and its audit, no parallel log to drift from | The full event stream for any case, with actor + timestamp on every action |
| Records retention — closed-case data kept for the required period, then handled per policy | Retention in Record — policy over the same case-keyed store | The retention rule per case type, and the closed-case records still on the store within the retention window |
| Legal hold — records placed on hold survive routine retention and are produced on request | Retention in Record — a hold is a flag over the same store; held records are exempted from purge | The hold list, and a hold’s records produced through the API |
| Access decisions are recorded — every read and write is attributable to a provisioned identity | Access — authentication and authorization on every request, both recorded as Events on the case | The events for any case showing which identity opened the document, edited the issue, signed the work product |
| Role enforcement — privileged actions gated by capability | Access — each endpoint declares the capability it requires; a request without it returns 403 with the missing capability named | The capability set per Role; the audit log of refused requests |
| Document-level permissions — only authorized viewers see a given case’s documents | Access — enforced at the Record layer, not in the UI | The deny response from storage when an unauthorized request is constructed |
| Data residency — case data stays inside a chosen environment | Single-tenant, self-hostable deployment — the case lives in the customer’s own account | The deployment’s environment topology |
| Configuration change history — the shape of the operation has the same audit as the work | Admin — every configuration change is an Event in the event history | The change history for any configured object (case type, rule, queue, role, boilerplate entry) |
The sections below describe each mechanism in more detail; the map above is the quick reference for an evaluator reading top-to-bottom.
Isolation — protecting the record
The privacy obligation — one party’s record stays sealed from another’s — is enforced structurally, not by policy the application has to remember to apply: the per-case key boundary and the per-deployment (tenant) account boundary in Record. Single-tenant, self-hostable deployment also lets an operator satisfy data-residency and data-handling requirements directly, since a customer’s data lives in a customer’s own account.
Traceability — the audit trail
Every action is a stored, append-only event scoped to its case: who did what, to which document, when, and how long it sat at each step. Views, edits, searches, tags, status changes, routing decisions, and configuration changes all leave a record. Because the audit trail is the same case-keyed data as everything else, you can reconstruct exactly what a reviewer saw on the day they relied on it — the basis for a defensible, reviewable decision.
Retention
Retention is policy over those same records: how long a deployment keeps closed-case data, what’s held, and what’s produced on a records request. Because every artifact is keyed by case with an actor and a timestamp, retention and legal hold operate over one consistent store — covered under Record.
Access control
Who may open which cases, and who may take which actions, is governed by Access — provisioned identities, roles that gate capabilities, document-level permissions, and team-based assignment. Authentication binds to an identity provider or uses the platform’s own; either way authorization is a fresh, expiring credential.
Encoding the rules
Regulatory and policy logic changes, and the system has to change with it — intake categorization, eligibility, routing, and gating. Those rules live as configurable business rules in Admin, adjusted as the rules evolve without a release, and quality-review gates carry their policy in the workflow shape. The system of record and its data-security posture are the foundation the rest of these mechanisms stand on.
The record the regulation asks for
Compliance is also a matter of having the right data to show. Because the platform is state-first and every action is an event, the record captures a case’s full lifecycle — every queue movement, status, the actor behind each step, and how long it sat at each — and a deployment configures the data elements it categorizes by. So the data a governing statute or reporting regime asks for is already on the record, queryable in real time and read live by Reporting, rather than reconstructed after the fact.