Connect

Moves objects across the boundary — in from source systems, out to delivery and reporting

Adjudicate is a component, not a closed app — it connects in two directions, and Connect is the model for both.

Connect is the loop’s outer ring — the ports are where the loop meets the outside world. Intake feeds the center: the document source, party/identity, case/status, and correspondence ports take a case in so a reviewer can read its evidence and decide its issues. Dispatch carries the center’s output back out: the output/effectuation and authoring ports ship the Reader-derived result outward — the decided issues and their cited evidence, the seam crossing the boundary. Reporting reads the live record off to the side; scheduling and conferencing serve Sessions, whose transcripts re-enter the loop as evidence on the case.

Connect to Adjudicate

A real HTTP Integration API and a typed SDK let another system read and write case data — list cases, read documents, search, add tags and annotations, set a document’s read state — authenticated on every request against the same identity a person signs in with. It runs live in an isolated, synthetic-data environment you can call today; that’s the concrete integration surface for an intake system handing a case in or a drafting tool pulling evidence out. The same API bulk-loads a backlog of historical cases when a deployment migrates from a prior system, and pulls a local copy of a case’s file — one document or the whole assembled case — back out on demand.

Adjudicate connects to your systems

For any capability around the edge of a case, the core talks to a vendor-neutral port, and a per-deployment adapter binds that port either to a system already in place or to a platform-provided baseline. The ports:

Port detail

Each port is documented below — what it exposes, the events on the platform side that reach across it, the platform-provided baseline a deployment can run without integration, and the typical integration shapes a bound adapter takes.

Document source

The document source supplies the case file. The core asks the port for a list of available documents on a case, the bytes for one document, and a stream of new arrivals the source has produced since a last-seen marker; it offers the port a write back hook for documents the case acquires after intake (a session transcript, a corresponding letter the platform sent out, an annotated copy). Each document carries enough identifying metadata for the platform’s deduplication layer — content hash, source identifier, receipt date, suggested category — that AI can recognize duplicates without re-reading every byte.

Events that reach the port outbound: a case is opened (the port is asked for its known documents); a session produces an artifact (the port is told). Inbound: a new submission arrives at the source and is pulled into intake; a document already in flight updates and the case picks up the revision.

The platform-provided baseline takes documents in at the port — an intake system hands the document and its metadata to the case — and the Integration API serves a local copy back out (one document or the whole assembled file). A deployment that runs its own document store binds the port to it; the typical shape is a thin adapter that fetches by external id and translates the store’s metadata into the platform’s document shape on the way in.

Authoring

The authoring port is the seam an external word processor binds to — and it is the issue ↔ evidence seam crossing the boundary: what crosses is the decided issues and the evidence pages they cite, carried out of the center unchanged. The core supplies the live evidence on the case (documents, page anchors, annotations), the unified issue list with each issue’s scope and disposition, and the boilerplate library the deployment maintains; it accepts back the composed document and the per-issue disposition the author resolved on. Citations from the evidence resolve to the same page anchors the platform uses everywhere.

Events outbound: a case is assigned for drafting (the port is asked to open the editor on the case with the evidence and issue list loaded); a boilerplate entry updates (the port is told). Inbound: the author saves a draft (the port writes the work product); the author signs (the port commits the signing transition through the platform).

The platform-provided baseline is the native Authoring surface — the document is composed in the case in the Workspace, against the live record. Binding an external editor swaps the surface; the work product, the issue dispositions, and the event history are identical either way.

Output & effectuation

This is the outbound side of a signed outcome — the point where what the center produced leaves the loop. The core hands the port the decision package — the signed work product, the dispositions per issue, the recipients drawn from the case’s parties — and this package is the seam crossing the boundary: the reviewer’s decided issues, each carrying its disposition and citing the evidence pages that prove it, dispatched to whoever needs it. The port performs the delivery: printing, mailing, electronic transmission to a downstream system of record, propagation into a benefits database. The port acknowledges back with a delivery receipt — when the package went out, by what channel, with what tracking — which lands on the case as an Event.

Events outbound: a work product transitions to signed (the port is given the package). Inbound: a delivery receipt comes back from the adapter (the case picks it up); a downstream system reports the effectuation completed or failed (the case is updated, and an escalation task opens on a failure).

The platform-provided baseline assembles the package and exposes it at GET /cases/{id}/decision-package for a polling adapter, or writes it to a deployment-specified outbound location. The typical integration shape is an adapter that subscribes to the workProduct.signed event, fetches the package, and dispatches through whatever print, mail, or downstream API the deployment uses.

Notifications

The notifications port sends alerts to people on case events. The core emits a stream of events — a case docketed, a task assigned, a session scheduled, a draft ready for review, a deadline approaching — and the port routes each one to the right channels for the right recipients. Channel is part of the adapter (email, text, in-app, push); recipient resolution and the per-event template are Admin configuration, so which events notify whom on which channel is set by the deployment without a release.

Events outbound: every action on a case that the deployment has subscribed to (the subscription set itself is configuration). Inbound: a delivery receipt or a bounce comes back, which lands on the case as an Event so the operation can see what reached whom.

The platform-provided baseline raises in-app alerts natively on a person’s own work — a task assigned to me, a comment left on a draft I authored — and exposes the event stream so an outbound adapter can subscribe to it for email, text, or other channels. A deployment that already runs a notification service binds the port to it; the typical shape is an adapter that subscribes to the event stream and translates each event into the service’s send-call.

Reporting

The reporting port hands the operation’s data to a reporting or BI tool — the integration side of the Reporting capability. Because the platform is state-first and event-sourced, the reporting surface is live — the port reads the current state of every case (status, assignee, age in each step) and the full event history, and a reporting tool queries against it directly rather than against a nightly export to a separate warehouse. The port also exposes the data elements the operation categorizes by, so a BI tool’s dimensions match what the operation’s authors and operators see.

Events outbound: the port serves reads — the state and the event stream — on a pull schedule the reporting tool sets. Inbound: a saved report is pushed back as a Admin-configurable dashboard the operation’s roles see in the Workspace.

The platform-provided baseline is a standard set of reports and dashboards — see Reporting for the catalog — rendered in the Workspace and queryable as the operation runs.

A deployment that runs its own BI tool binds the port to it; the typical shape is a connector that reads the case-state and event endpoints on a schedule and lands the rows into the tool’s warehouse layer. The standard reports above run regardless — the platform renders them in the Workspace whether or not an external BI tool is bound.

Party & identity

The party-and-identity port resolves a Party on a case against the deployment’s directory of record. The core looks up a party by an external identifier (or by name + date-of-birth when the identifier hasn’t been resolved yet), reads back the canonical record (legal name, contact information, current address, representation), and accepts a change-stream of updates so the case’s view of a party stays current when the directory’s record changes — a marriage that changes a name, an address update, a representation switch, a power-of-attorney revocation.

Events outbound: a party is added to a case (the port is asked for the canonical record); a contact detail on a case-side party is edited (the port is asked to write the change back, if the directory accepts writes). Inbound: the directory reports a change (the port pushes the update onto every case that party appears on); a representative is reassigned or revoked (the port pushes the new representation onto the affected cases). The platform records each change as an Event on the case so the party’s history is visible at the case level, not just at the directory.

The platform-provided baseline keeps the party record on the case itself — POST /cases/{id}/parties/{partyId} writes the record, subsequent updates overwrite it, and the change history is the audit trail. A deployment that already runs a party-of-record directory binds the port to it; the typical shape is an adapter that resolves on first reference (a lazy lookup against the directory’s API), caches the canonical record on the case, and subscribes to the directory’s change stream to push updates onto every case the party appears on.

Case & status

The case-and-status port is the bidirectional seam with a system of record outside Adjudicate. Two directions cross it:

• In — an upstream system that owns the canonical case identifier (a benefits system that handed a request to the operation, a court that referred a matter) hands new cases over for the platform to docket and supplies updates to their type or external status as it learns of them.
• Out — a downstream system that needs to know about the case (a benefits database tracking the request’s progress, a public-facing portal showing the appellant where their matter stands, an oversight system aggregating across operations) reads the platform’s derived state and event stream and stays current.

Events outbound: a case is created (the port is asked to register it upstream and announce it downstream); a case’s state transitions (the port pushes the new state to subscribers); a case closes (the port announces closure with the signed outcome’s identifier). Inbound: an upstream system reports a status change relevant to the case (the port writes it as an Event); an upstream system retracts a case (the port records the retraction, and the platform’s workflow decides whether to close or pause).

The platform-provided baseline serves the case and its derived state at GET /cases/{id} and GET /cases/{id}/state and exposes the event stream at GET /cases/{id}/events — a downstream system polls these on its schedule. A deployment with an existing system of record binds the port to it; the typical shape is an adapter that subscribes to the platform’s event stream, translates each state transition into the system of record’s own status vocabulary, and posts updates back through whatever API that system exposes — plus a webhook the upstream pushes into when its own status changes.

Scheduling

The scheduling port supplies the calendar a Session is placed on. The core asks the port for participant availability (the windows each named participant — adjudicator, representative, location, room — is free) and the configured blackout dates; it submits a suggested slot for conflict-checking before booking; it commits a booking once the slot clears. The bookings themselves live on the case as Sessions, so a placed session and a scheduled task are the same record seen two ways.

Events outbound: a case requests a session (the port is asked for availability and suggests slots); a placed session is rescheduled (the port frees the old slot and reserves the new); a session is withdrawn or postponed past its window (the port releases the slot back to availability). Inbound: a participant’s availability changes (the port pushes the change, and the platform flags any placed session that now conflicts with it); a blackout is added (the port pushes the change; affected sessions surface as a conflict for a scheduler to resolve).

The platform-provided baseline carries availability and blackouts as configured data per participant and location, runs the conflict-check against the existing Session set on the same tenant, and serves the scheduler’s prioritized national queue of cases waiting to be placed. A deployment that already runs a calendar or resource-scheduling system binds the port to it; the typical shape is an adapter that proxies availability lookups, mirrors blackouts, and writes commit-on-book back to the external calendar so the same booking shows up in both places without a drift-prone sync job.

Conferencing

The conferencing port hosts the remote portion of a Session. The core asks the port to create a conference when a session is placed on the calendar — the port returns a host join URL, a participant join URL, and a handle the session carries from then on. The platform fetches the current conference detail at session time (URLs may rotate, so the platform pulls fresh rather than caching), cancels the conference when the session is withdrawn or postponed past its window, and collects artifacts when the session is held — the audio recording, the transcript if the conferencing service produced one. Each artifact enters the case as a Document (the same data model every other piece of evidence uses), indexed and searchable like any other.

Events outbound: a session is scheduled (the port is asked to create); a session is rescheduled (the port updates the existing conference or replaces it); a session is held (the port is asked for artifacts); a session is withdrawn or postponed past its window (the port is asked to cancel). Inbound: a participant joins or leaves (the port reports presence, which the platform writes as an Event on the session); the recording is ready (the port hands over the artifact bytes).

The platform-provided baseline supplies in-app session hosting with audio capture and an automatic transcript step; the artifacts land directly on the case. A deployment that already runs a conferencing service binds the port to it; the typical shape is an adapter that wraps the service’s room-creation and webhook APIs, normalizes the artifact filenames and types, and posts back the recording and transcript as Documents when the service signals they’re ready. Session-time URL rotation, recording-consent prompts, and waiting-room behavior are part of the bound service’s settings, not the core.

Correspondence

Correspondence is the two-way flow of filings and letters between the operation and the people on a case. Inbound: the port takes in a piece of correspondence — a filing, a status inquiry, a returned mail item, a representation change — and resolves it onto the case it concerns. The port carries the channel it arrived on (mail, fax, electronic submission, portal upload), the sender, the receipt date, and the bytes; the platform writes it as a Document on the case, opens a task of the matching mail-routing type (a representation-change task, an evidence-and-argument task, a privacy-act request, a withdrawal), and runs the inbound through AI intake deduplication when it matches an existing case.

Outbound: the platform composes the letter or notice from the deployment’s boilerplate library, fills the case-specific fields from the live record, and hands the assembled correspondence to the port for distribution — print, mail, electronic transmission, portal post. The dispatch lands on the case as a sent Document with a delivery receipt Event when the adapter acknowledges; a bounce or undeliverable returns inbound and opens a returned-correspondence task.

Events outbound: a signed outcome raises a notice; a task routes a status letter; a configured business rule sends a deadline reminder. Inbound: a piece arrives at the source and is taken in (the port is asked); a delivery receipt or bounce comes back from the outbound channel (the case picks it up).

The platform-provided baseline accepts inbound correspondence through the Integration API as Documents on the case, composes outbound from boilerplate and exposes the assembled bytes at a deployment-specified outbound location, and runs the inbound mail-routing task catalog the default profile ships with. A deployment that already runs a mail-handling system binds the port to it; the typical shape is an adapter that polls the mail system for new inbound, translates each piece into a Document plus the matching mail-routing task type, and submits outbound through the system’s existing send-call.

Integrate or provide

Each port is integrate-or-provide: bind it to an existing system, or let the platform supply a baseline. Swapping one for the other is configuration at the adapter, not a change to the core — which is what lets the same product drop into an environment that already has these systems and stand up the whole stack where it doesn’t. Notifications are a clear example: they’re event-triggered — a case docketed, a session scheduled, a task completed — and which events notify whom, on which channel, is configured. The platform raises in-app alerts on a person’s own work natively; the outbound channels (email, text) are a port bound to a delivery service.

What stays constant

Whatever an adapter binds to, the core only ever speaks to the port — so the data model, the work engine, and every surface are indifferent to which system is on the other side. The boundary is the same whether a deployment adopts the whole platform or just the Reader and integrates the rest.