# Orchestrate.legal Reference Model v0.1

**Status:** working reference (draft for discussion)  
**Site:** https://orchestrate.legal/model  

This document mirrors the on-site reference model. It is **not legal advice** and not a substitute for firm-specific counsel or engineering design.

---

## Design commitments

- 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. This matters even more for agentic AI, where systems may plan, call tools, update records or trigger follow-on actions rather than only produce text.

---

## Primary flow

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

| Term | Definition |
|------|------------|
| **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, etc. 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. |

---

## Core concepts (extended)

- **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.
- **Execution gate:** A required pause before reliance; belongs at the point of use.
- **Matter state:** Operational position of the matter across time.
- **Audit trail:** Composed of audit events; supports accountability and replay.
- **Monitoring:** Signals after deployment: drift, failure modes, rework rates and escalation paths.

---

## How to use this model

### 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.

---

## 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?

---

## Related assets

- Routing policy template: `routing-policy-template.md` (same folder)
- Execution gate matrix: `execution-gate-matrix.md` (same folder)

---

*Independent research and writing. Not affiliated with any single vendor or employer brand.*