Orchestrate.legal

Reference model v0.1

A working reference for discussion: shared vocabulary between legal, risk and engineering. Version 0.1 is intentionally compact; extend it in your own templates and policies.

Use this page as a checklist: define route policy, set gate thresholds by destination and reliance, and confirm that matter state plus audit are captured before output is used.

Design commitments

A compact set of design commitments that anchor the model.

  • Legal AI should be designed around coordinated work, not isolated answers.
  • The firm should own the routing layer between legal intent, model execution and human judgement.
  • Controls should sit at the point of reliance, not only at the point of generation.
  • Matter state should be treated as a live operational record, not a folder of documents.
  • Evaluation should measure rework, variance and degradation over time, not just first-pass accuracy.

What is orchestration?

Orchestration is the layer between legal intent and execution. It decides what work is being requested, what context is required, which path (model, tool, human, policy check) should run, whether the output may proceed, what is logged and how matter state updates. It is not a synonym for automation. It implies sequencing, coordination, judgement and control. The distinction matters even more for agentic AI, where systems may plan, call tools, update records or trigger follow-on actions rather than only produce text.

Orchestration loop

Between isolated Q&A and coordinated work: intent moves through routing and execution, then gates, state, audit and monitoring before the next task.

Orchestration loop

Each cycle connects intent to execution, then gates reliance, updates matter state and the audit trail, and feeds monitoring back into routing.

Task
Plan
Route
Execute
Review / Gate

Control point

Matter + Audit
Monitor

Primary flow

Demos, playbooks and writing all use this backbone; treat it as the shared spine for design and policy discussions.

  1. A legal task is requested.
  2. The system identifies the type of work.
  3. The system gathers the right context.
  4. A routing decision is made.
  5. The task is executed by a model, tool or human.
  6. The output is checked against the intended use.
  7. An execution gate determines whether it can proceed.
  8. The matter state is updated.
  9. The audit trail records the decision.
  10. Monitoring continues where needed.

Terminology

Short definitions you can lift into architecture reviews, gate workshops and vendor questionnaires.

Route
The chosen path for a task: model tier, tool, environment, retrieval posture, human steps, cost controls and governance band, selected under a named policy version.
Gate
A required pause before an output reaches a destination: review, approval, block, logging or escalation. Gates encode policy at the point of use.
Reliance
How strongly the organisation or client is expected to treat the output as authoritative, from draft assistance through to binding use.
Destination
Where the output goes next: internal notes, working group, client channel, filing system, regulator, court bundle, and so on. Risk follows the destination.
Mandate
The scope of authority for automation or AI assistance on a matter or work type: who may trigger it, within which boundaries, and under which supervision.
Matter state
The live picture of phase, open tasks, pending decisions, obligations and risks, not a static file list.
Audit event
A durable record of who ran what, on which policy version, with which inputs, evidence, gate outcome and reviewer actions.

Concepts

How the pieces fit together in operating models and tooling discussions.

Task
The unit of work: an owner, inputs and a definition of done. Tasks chain; documents attach to them.
Context
What the model and reviewer may see: matter phase, sensitivity, prior decisions and retrieved sources.
Router
Policy that maps task attributes to path: model tier, environment, retrieval, human steps, cost controls and governance band.
Execution gate
A required pause: review, approval, block or audit before an output reaches a destination. Gates belong at the point of use.
Matter state
The live picture of phase, open tasks, pending decisions, obligations and risks, not a static file list.
Audit trail
Who ran what, on which policy version, with which inputs, evidence and reviewer actions attached.
Monitoring
Signals after deployment: drift, failure modes, rework rates and escalation paths.

How to use this model

Practical entry points by function, without needing the whole mental map on day one.

Product and engineering teams
  • Use the primary flow as a backlog lens: every feature should declare which step it affects and what state it updates.
  • Treat route and gate as first-class data models, not UI afterthoughts.
  • Ship with policy version IDs on every automated path.
Risk and compliance
  • Map each work type to reliance and destination; gates should differ materially when either changes.
  • Ask for audit events that explain why a path was allowed, not only what the model produced.
  • Review mandates when client terms, jurisdiction or matter phase changes.
Legal operations and innovation
  • Use the demos as discussion props: routing simulator, matter state viewer, execution gates.
  • Anchor change management in matter state: who owns updates when AI is in the loop.

Downloadable assets

Markdown files you can version in Git, paste into a risk pack or print to PDF from your browser.

Open questions

  • How should routing policies change across matter type, client terms and jurisdiction?
  • What evidence is enough before AI-generated work can leave the firm?
  • How can firms use multiple AI tools without fragmenting audit, policy and accountability?
  • When should matter state trigger automation, and when should it only guide human judgement?

See the Routing Simulator, Matter State Viewer and Execution Gates demos for concrete examples. New to the site? Start here.