Admin

Objects — Member · Team · Role · Case type · Task type · Queue · Boilerplate · Rule · Issue set

Admin is where a deployment shapes the generic platform into its operation. Everything below the configuration line — the data model, the work engine, the Reader, Access — is identical for every customer. Admin is the layer above it, where a privileged user defines the tenant-scoped objects that make a deployment specific. Shaping an operation here is configuration, not a code change, and that distinction is what keeps the product commercial: one core, configured many ways, never forked per customer.

What you set here configures the whole loop a case runs through. The Reader — the document-review workstation where evidence becomes judgment — sits at the center; the loop around it (intake, the queues that feed the Reader its next case, the issue sets the Reader decides against, the boilerplate Authoring composes from, the sessions and their dispositions, dispatch out) is configured object by object in Admin. The center is the same product for everyone; the loop is the one this operation defined.

What you configure

Case types — the kinds of case the operation handles, each with its own workflow, eligibility rules, and issue set.
Task types & workflows — the steps a case moves through. A process is composed from the platform’s task-type library — adapted or extended with a deployment’s own — into the workflow a case type runs, with the holds, branches, and gates it needs. Adding a new queue is one such change, made here rather than in a release.
Queues & distribution — the saved, ordered views work flows into, and the distribution levers (batch size, wait thresholds, lane balancing, priority) that fill them — tunable, testable against current work before they apply, and audited.
Roles & permissions — the capability sets that gate what each identity may do, and which cases and documents it may reach.
Business rules — the logic that drives assignment, eligibility, routing, priority, and gating, expressed as configuration a privileged user maintains. When a court decision or policy shifts how intake is categorized or how a case routes, the rule is edited here and applies without a release.
Issue sets — the dispositions (granted, denied, remanded, and the finer reasons beneath them), categories, and special-issue flags the operation’s issues carry — the vocabulary an issue is resolved from.
Boilerplate — the reusable authoring content library.
Data elements — the value sets the operation uses, such as quality-review error reasons and session dispositions, added or retired as the work changes.

Adjudicate ships configured

A deployment does not start from an empty engine. The platform ships with a default profile — a complete configured operation for adjudication work — that a deployment uses as-is, adapts, or replaces from. The profile configures the whole loop end to end: the case types a case is taken in as, the queues that feed the Reader its next case, the issue sets the Reader decides against, the boilerplate Authoring composes a decision from, and the sessions and dispositions that round the loop out. It carries:

A library of case types for the common shapes of adjudication: an appeal, a higher-level review, a supplemental claim, a court remand, a follow-on motion stream.
A library of task types covering the breadth of the work — review and decision, assignment and reassignment, sessions and their scheduling, motions and post-decision actions, correspondence in and out, administrative support, holds and timers, distribution and routing.
Role and team templates — the roles common to an adjudication operation (reviewer, decider, supervisor, support, operator) and the teams they group into, with capability sets pre-mapped.
Queue layouts and distribution lanes — saved queries over the task tree, organized by lane (priority, hearings, regular, follow-on), with sensible default distribution levers per lane.
Hearing types — in person, by video, by phone, fully virtual — with the session dispositions each can carry.
Motion flows — vacate, de novo, court remand — and the case-stream behavior each produces.
Issue sets — the disposition vocabularies, categories, and special-issue flags common to the work; remand reasons and their sub-codes pre-populated.
A boilerplate library — reusable language for the recurring sections of a decision, indexed by issue type and disposition.
Business rules — eligibility checks, routing-on-disposition, follow-on triggers, deadlines and escalations — the rules every adjudication operation runs in some form.

Every element of the profile is data the deployment owns. An operator opens any of the above in Admin and edits it: adds a case type the operation handles that the default doesn’t, retires a task type that doesn’t apply, rewires the routing rules, replaces a boilerplate library with the operation’s own. The default is a starting point, not a fixed core — a deployment that operates very differently from the default replaces the whole profile and keeps the same engine.

The profile is what makes the engine generic and the operation specific at the same time. The platform you run is the platform every other customer runs; the configuration on top of it is the one this operation defined.

Overriding the default — two worked examples

Tightening an escalation. The default profile attaches a 30-day timer to the evidence-window task type, with escalation flag — when the window expires the task is flagged for review and the case stays where it is. An operation that needs the case actively moved on expiry opens the task type in Admin and changes the escalation to reassign-supervisor, saves, and the change applies to every new evidence-window task that opens from that point on. Tasks already open inherit their original escalation; the change is recorded in the event history with the operator and the time. No release, no code change — the task-type record itself is data the deployment owns.

Adding a queue for a sub-population. A team starts handling a new sub-population of cases — say, cases with a special-issue flag the deployment just added — and wants a saved queue for them. The operator opens Queues in Admin, names the queue, sets the filter (special_issue: <flag>, status: open), picks the team that owns it, and saves. The queue immediately appears in the Workspace sidebar of every member of that team. The distribution levers for the new queue pick up the lane defaults; the operator tunes them — batch size, wait threshold, priority — and tests the change against current work before applying. Everything that happens after — assignments, escalations, completions — flows through the same task tree the rest of the operation runs on.

The shape of both examples is the same: open the configured object, change a field, save. The platform underneath does not know which fields are defaults and which are overrides — every value in the profile is data, edited the same way regardless of where it started.

One core, configured per deployment

A change to any of these is a configuration change a deployment makes for itself — a new case type, a revised workflow, an added queue, a changed rule — applied without a release, against a shared core that stays the same for everyone. Process logic lives as configuration, so when an operation’s rules change, the configuration changes with them while the engine stays the same. A distribution change can be tested against current work before it applies, and every change is recorded — so reshaping the operation is governed configuration, never a modification to the product. That is the commercial shape: the platform you run is the same platform every other customer runs, shaped by what you set here.

The configurable interface

Admin also holds the interface configuration that follows a user. A reviewer’s landing is their worklist — the dense, sortable table of the cases waiting on them — not a generic home, and their sorting and filtering preferences on a queue are saved and reapply automatically every time that queue opens, so a view someone tuned once stays tuned. A dashboard is one configurable view alongside the worklist — a role-tuned summary of the tasks, suggestions, and metrics relevant to the work in front of someone — composed in Admin as part of a role’s default layout and pinned or hidden per member. The product adapts to the role and the person without a per-customer build.

Everything configured is audited

Every configuration change is a record like any other — who changed what, when — in the event history, so the shape of the operation has the same traceability as the work that runs on it.