Sessions

Objects — Session

Some cases need a session — a hearing or proceeding — before they can be decided. Sessions is the loop station that schedules one when a case needs it, runs it, and folds what comes out of it back into the case: the recording and transcript re-enter the Reader as evidence, so a held hearing closes the loop back at the center. At its core it’s a resource-scheduling problem: placing a session into the availability of several people and places at once. In the work people do day to day it surfaces as the calendar — one station on the loop the Workspace runs around the Reader, not a separate place; underneath, a session is a task on the case’s tree, so scheduling is one more kind of work on the same engine.

Session types

A deployment supports several kinds of session — in person, by video, by phone, or fully virtual on a national basis — and each case’s session is set to the kind that fits. The kind a case gets is configuration; the scheduling and capture below work the same across all of them.

Scheduling

A session has to land in a slot that works for everyone involved — the adjudicator, the representative, the party, and a room or a virtual location. The scheduler works from each participant’s availability and blackout dates, proposes conflict-free slots, and prevents double-booking. Scheduling spans two scales of work:

• Build the schedule. A scheduler lays out the available days and time slots ahead of time — drawn from participant availability and blackout dates, by location — so the calendar a case is placed onto already reflects who and what is free. Dockets can also be created automatically from criteria, so a deployment that schedules at volume generates its forward calendar rather than building each day by hand.
• Place the case. Against that calendar a scheduler picks a session type and an open slot for a specific case, sees the case and its evidence alongside the choice, and books it — with conflicts blocked at the point of booking.

To feed that work, each scheduler gets a prioritized national queue of cases waiting to be placed, ordered so the cases that should be heard first surface first, and a privileged user assigns cases from it to the schedulers who will place them.

A placed session begins as a schedule task. Once a slot is set, dependent work — a draft that waits on the session — sits on hold until the date passes, on the same hold mechanism the work engine uses everywhere. Rescheduling, conversion between session types, and withdrawal update the same task, so the case keeps the full trail.

The schedule, the docket, and assigned sessions

Three surfaces read the same scheduled sessions, each for a different rhythm of work:

• The schedule — the full forward calendar of placed sessions, for planning and editing the days ahead.
• The day’s docket — every session set for a given day, in order; the surface the day is run from, where a privileged user records each session’s disposition as it happens and prints the docket for the bench.
• Assigned sessions — a participant’s own upcoming sessions, prioritized — the personal worklist of what’s next.

From any of them a user opens a session to see its details alongside the case and its evidence, and to modify what the case needs.

Holding a session

Sessions are typically held remotely, so the platform provides or integrates a conferencing service to host them — bound through the conferencing port. Capture is deliberate: a session yields an audio recording and a transcription, and audio and transcript are the session’s record by configuration — so a deployment that requires audio-only capture is satisfied directly.

The worksheet

Each session has a worksheet — the adjudicator’s working surface for the proceeding, and where the seam reaches Sessions. A privileged user records notes and the disposition (held, no-show, withdrawn, postponed) and works it against the case’s issues and the documents that are their evidence: the issues in play are listed, pre-hearing impressions and per-issue notes attach to them, and the evidence is one click from the Reader. The worksheet is part of the case, so what’s captured at the session is immediately on the record rather than in a separate place to reconcile, and a printable version goes on the bench.

What the session leaves behind

What the platform keeps about a held session is small and concrete, and it points back at the center:

• disposition — a configured value, the way an issue’s dispositions are — which routes the next task by rule (the table below);
• the participants — drawn from the case’s parties;
• artifacts — the transcript and recording enter the data model as documents on the case, indexed and searchable in the Reader like any other evidence. This is the loop closing: a hearing’s output lands back as evidence the reviewer reads, the same as any other document in the file.

A deployment configures its session dispositions and the routing rule each one fires. Held and no-show route by default; withdrawn, postponed, and converted are dispositions a deployment commonly adds. A representative profile wires all five:

Each rule is editable in Admin — a deployment that handles a disposition differently rewires the routing without a release. Because the transcript is just another document, it’s immediately citable in the Reader, and the session and the case share one record rather than two repositories that have to stay in sync. Notifications to participants ride the notification port; when a deployment already runs a scheduling system, the calendar itself is a port bound to it.