Case study · 01 · ~ 6 minutes

A controlled system for formal legal correspondence.

A law-first drafting workflow for formal correspondence across repeat document types - built around source discipline, firm voice, standing legal checks, and a final human review gate before anything is dispatched.

Role
Built solo as Founder and Division Lead of an in-firm AI legal-technology division.
Scope
Ten formal document types across a small commercial practice.
Stack
Skill-based assistants, structured rules, reference library, DOCX templates.
Outcome
Drafting becomes repeatable. Reviewer attention shifts from style to issue spotting.
Legal correspondence architecture A left-to-right pipeline. Source material on the left passes through a doctype router, voice rules, standing checks, and references. The pipeline narrows into a tall reviewer gate at the centre right, which is the dominant visual element. Only after the reviewer gate do approved outputs emerge as formal opinions, advice notes, transmittals, and execution checklists. A dashed feedback arc shows reviewer edits flowing back into the rules and references. Legal correspondence architecture SOURCE → SKILLS → GATE → DISPATCH 01 · INPUTS Source material Client instruction Draft agreement Reference library Matter context Standing positions Missing facts are bracketed, never invented. 02 · SKILL LAYER DOCTYPE ROUTER Opinion · advice · letter · transmittal VOICE RULES Firm voice · British English · Clause caps STANDING CHECKS Clause review · authority Execution discipline REFERENCE IDS Doc sequence · cross-referencing SELF-CHECK PASS An automated finality check runs before the document reaches the reviewer. Each skill is a discrete contract, not a single prompt. 03 · GATE HUMAN REVIEW Reviewer decides whether to dispatch 04 · DISPATCH Approved outputs Formal opinion Advice note Transmittal Execution checklist Demand letter Execution only after final-version and signer checks. REVIEWER EDITS · feedback into rules and references
Fig. 1 Pipeline view. Source material moves left to right through a skill layer into a human reviewer gate; only approved outputs leave the firm.
§ 1

Problem

The operational issue was not simply drafting speed. The harder problem was legal consistency: the same practice needed formal legal opinions, advice notes, client letters, transmittals, execution checklists, fee requests, periodic reports, demand letters, acknowledgements, and internal memoranda to follow the same voice, legal posture, and document discipline.

Generic prompting did not solve that. It produced plausible text, but it did not reliably preserve firm voice, apply standing review positions, assign references, or distinguish an internal discussion from a dispatch-ready document.

§ 2

System

The workflow is a set of specialised skills and reference files rather than a single prompt. That distinction matters: a legal opinion is not just generated text - it is the firm's position, based on source material, expressed in a controlled form. The system separates the task into discrete stages, each with its own contract, so that nothing about the document is produced incidentally.

The point was to encode drafting judgment as a workflow, not to encode generic legal prose into a model.

Each document type has a known structure. External documents use a controlled register, fixed terminology, and disciplined closings appropriate to formal correspondence. Internal discussion stays direct, because the reviewer needs advice rather than a letter.

§ 3

Validation, and the human gate

The final gate is still human. The system runs an automated finality check against a defined set of criteria before the document reaches the reviewer, but the reviewer decides whether the advice should be dispatched. The check exists to remove the routine failure modes from the reviewer's attention, not to substitute for it.

Execution-stage documents move into a separate signing workflow, described in the document execution case study. That workflow treats finality, signer authority, attachment completeness, and audit trail as its own control problem.

§ 4

Open problem

The next step is stronger evaluation. The useful measure is not whether the text sounds legal. It is whether partner edits reduce over time, whether issue spotting improves across document types, and whether the finality gate catches the same problems a senior reviewer would catch.

This page describes the architecture. The private implementation - the templates, the standing positions, the validation rules - stays with the firm. The portfolio is the demonstration; the work is where it happens.

Next case study

The deal-desk operating system