Access
Objects — Member · Team · Role
Access answers two questions: who is asking (authentication) and what they may reach and do (authorization). One sign-in settles the first and drives the second — a single identity authorizes everything that follows, the Reader’s direct reads and the Integration API. There is no separate API key and no long-lived secret in the client; authorization is always a fresh, expiring token bound to a provisioned identity.
Members, identities, and the lifecycle
A member is a person who can sign in and act in a deployment — with a name, contact, role grants, team memberships, and a lifecycle. Members are the tenant-scoped projection of an identity (the platform-wide login). One identity may belong to many tenants; a member exists in exactly one. Adding someone to a deployment means provisioning a member record bound to their identity; removing them means deactivating the member, never the identity.
The chain: sign-in → token → scoped credentials
- Sign-in. A member authenticates against the deployment’s identity provider — a passkey or a password. A successful sign-in yields a short-lived token plus a refresh token.
- Federation. That token is exchanged for temporary, scoped credentials (minutes-to-an-hour lifetime). This is what lets the browser read the datastore directly — the client never holds a static key.
- Access. The credentials (or the token, for the API) authorize reads. When they expire, the refresh token mints a new set silently; when that expires, the member signs in again.
The same token serves both access models below — one login, two doors.
Two access models
The platform reads its data two ways, for two kinds of caller:
- Client-direct. The Workspace holds the scoped credentials and reads the datastore and object store directly — no application server in the request path. Every page maps to one query against the record (the dashboard, the queue, the calendar, the case view, the Reader’s documents pane all follow this shape). The credential is the authorization, and it can only reach the case it was scoped to.
- Integration API. Other systems — intake tools, drafting environments, downstream systems of record, partners — present the token to the API, which validates it before any handler runs. The Workspace itself never hits this contract; the API exists for callers outside the product surface (Integration API).
Both start from the same sign-in. The only difference is what carries the authorization downstream: scoped credentials for the Workspace, the token for the API.
One identity provider
Authentication binds to a single identity provider — the deployment’s own, or one the platform supplies (the same integrate-or-provide seam used across the platform). That one provider issues both the token the API checks and the scoped credentials the Reader federates to, so a single sign-in authorizes both paths. Tokens are short-lived and revocable, and sign-in supports passkeys and passwords.
Identity vs. reach
A token proves identity; the data path independently governs what that identity returns.
- Authentication answers “is this a provisioned member, and is the token valid?” — the sign-in gate and the API’s token check.
- Isolation answers “which cases can this request reach?” — the per-case and tenant boundaries in Record.
- Roles answer “what may this member do?” — the capability gate below.
The isolation boundary holds the same way regardless of which access model carried the request in.
Roles
A role gates capabilities — what actions a member may take. Reviewing, deciding, administering, and configuring are distinct capabilities a role grants or withholds; a member may hold more than one role, and the same person can hold different roles in different deployments. Roles are orthogonal to isolation: a role widens or narrows what a member may do, while isolation governs which cases they may reach at all. Document-level permissions ride on the same model — only an authorized viewer sees a given case’s documents, enforced at the Record layer rather than hidden in the UI.
Roles are configuration, not code: a deployment defines its own set in Admin and maps them to capabilities. The appellate roles a court runs and the caseload roles a firm runs are the same mechanism, configured differently.
External participants ride the same model. A representative, a power of attorney, or an appellant is a provisioned member holding a role like any internal reviewer — its capability set is narrower (read the cases their role on the case authorizes, file what their role permits) and isolation scopes them to the cases they’re party to. There is no separate portal and no second authorization model: an external party signs in, federates to scoped credentials, and reads the one record through the same Workspace surfaces an internal reviewer uses, narrowed by the role they hold. The same capability gate and the same isolation boundary that hold inside the operation hold for them — the only difference is which role they carry.
The capability set
Each role is a set of named capabilities. A capability is the unit of authorization the platform checks: an endpoint or an action declares the capability it requires, and a request without it returns a 403 carrying the capability that was missing. The capabilities the platform ships with cover every mutation a deployment runs:
| Capability | Action it gates |
|---|---|
case.create | Create a new case |
case.read | Open a case the identity can reach |
issue.write | Write or update an Issue (scope, type, disposition, evidence) |
decisionIssue.write | Record a DecisionIssue (split-outcome record for an Issue) |
task.write | Create or update a Task |
task.reassign | Reassign a Task to a different person or team |
party.write | Add or update a Party on a case |
session.write | Schedule or update a Session |
workProduct.write | Save a draft Work product |
workProduct.sign | Sign a Work product (fixes the issue dispositions as the outcome) |
suggestion.decide | Accept, edit, or reject a AI suggestion |
substitution.write | Record an appellant substitution |
motion.write | File a post-decision motion |
taskTimer.write | Attach or clear an escalation timer on a task |
taskTimer.sweep | Apply expired escalation timers across a case |
distribution.run | Start a distribution run |
decisionPackage.read | Read the assembled outcome package |
config.write | Edit Admin configuration (case types, rules, queues, boilerplate, …) |
audit.read | Read the full case event history beyond what the working surfaces show |
A deployment composes these into the roles its operation runs — Reviewer gets the read + draft + suggestion-disposition set; Decider adds workProduct.sign; Supervisor adds task.reassign, distribution.run, and audit.read; Operator adds config.write. The default is “every authenticated caller has every capability”; enforcement turns on when a deployment seeds its Roles in Admin. Custom capabilities a deployment adds (e.g. a regulator-only audit.export for an oversight role) live on the same model.
Teams
A team groups members so work can be assigned to a group, not just a person. The work engine assigns a task to a team or an individual, and any team member can pick it up; reassignment moves work between them. Team membership is what routes a queue item to the right people. A member may sit on any number of teams, independent of which roles they hold — a senior reviewer may belong to a hearings team, a quality-review team, and a substitution team simultaneously without any role change. Privileged members add teams, add and remove team memberships, search for a member to see the teams they belong to, and view every team at a glance.
How Member, Role, and Team compose
The three objects answer three different questions, and they compose orthogonally:
| Object | Question | What it carries |
|---|---|---|
| Member | Who is this? | Identity binding, name, contact, status, role grants, team memberships |
| Role | What may they do? | A configured bundle of capabilities |
| Team | What work do they see? | A grouping that work routes to, independent of role |
A member’s effective authorization is the union of capabilities across the roles they hold; the work that appears in their queue is the union of tasks routed to the teams they sit on. Adding a hat means granting a role or adding a team membership — not editing a single hard-coded role string.
The account lifecycle
Account and permission management is itself integrate-or-provide: a deployment manages members and their permissions in a directory it already runs, or the platform provides the full account model below. Either way the capability gate and the audit trail are the same. Members are provisioned by a tenant administrator — there is no self-service signup in an adjudication deployment. Beyond creation, three operations matter:
- Edit — a privileged member updates account details (a name change on marriage, role grant added, team membership changed).
- Deactivate — a member is suspended or closed; a deactivated member receives no new work and signs in to no surface.
- Reassign — the open work the member was holding is moved, automatically by rule or by hand, to other members or queues, so deactivating someone never strands a case.
These are administrative operations; where they’re performed and configured is Admin, and every one of them lands in the event history as an auditable record.