Applying the methods to legal work

Legal engineering connects process knowledge to a system that can be built, tested, and operated. A useful way to see the connection is to follow one bounded improvement: making contract review requests more complete and their progress more visible.

The following example is synthetic. Its criteria and review arrangements illustrate system design; they are not a legal playbook for a particular organization.

Begin with the service problem

Suppose a legal team receives requests by email. Some omit the counterparty name or the relevant document version. People ask for clarification, forward the same messages, and struggle to tell who owns the next action.

The initial request may be “build an AI contract reviewer.” Process analysis can reveal an earlier problem: the reviewer receives unstable inputs. Improving intake and ownership may therefore be the first valuable change.

View the relationship model

flowchart TB
    O["OBSERVE<br/>Incomplete requests and repeated clarification"] --> M["MODEL<br/>Show the actual handoffs and waiting states"]
    M --> A["ANALYZE<br/>Test causes and identify ownership gaps"]
    A --> D["DESIGN<br/>Define complete intake and explicit exception handling"]
    D --> B["DELIVER<br/>Build a small, usable intake improvement"]
    B --> V["VERIFY<br/>Test valid, incomplete, and exceptional requests"]
    V --> E["EVALUATE<br/>Compare rework and service quality"]
    E -.-> O

The model gives the delivery team concrete work. The delivery process gives the model a route into practice. Domain expertise supplies the legal meaning of the criteria and the decisions that must remain with an authorized person.

Translate a model into a backlog

Each item should be small enough to deliver and meaningful enough to inspect. A first increment might handle one request type with a human reviewer and a reliable status record. More automation can follow when the team understands the exceptions.

Coordinate delivery without treating every matter as a Sprint

Scrum can help a team develop or improve the intake service. A Sprint Goal might be “make request completeness visible and enforce a correction path for the pilot team.” The team reviews a working increment and adjusts its next priorities.

The legal matters passing through the released service have different constraints. Court dates, contractual deadlines, urgent instructions, and review authority do not move because a Sprint has ended. A service may use a continuous work queue for incoming matters while its improvement team works in Sprints.

View the relationship model (Mermaid)

flowchart TB
    subgraph Product["SERVICE IMPROVEMENT"]
      G["Product goal"] --> S["Sprint: build and test a change"]
      S --> R["Released service version"]
      R --> F["Inspect outcomes and prioritize improvements"]
      F --> G
    end
    subgraph Matter["MATTER WORK"]
      I["Request and actual deadline"] --> W["Run the agreed workflow"]
      W --> H["Authorized legal review"]
      H --> O["Matter outcome"]
    end
    R --> W
    O -.->|Operational evidence| F

This distinction helps prevent two mistakes: using a delivery meeting as legal approval, and assuming that a successful legal outcome proves the underlying software is reliable.

Design for exceptions and judgment

Make missing facts, disputed inputs, unavailable sources, changed instructions, and unavailable reviewers visible. An unknown condition should not quietly become “no risk.” A delayed external response should become a waiting state with an owner.

Human review also needs usable inputs. Give the reviewer the relevant evidence, the exact decision requested, the applicable version of the criteria, and a record of uncertainty. “Human in the loop” is weak design if the human receives an unexplained answer and a single approval button.

Measure the outcome carefully

Track complete submissions, clarification cycles, elapsed time, active review time, and corrections after review. Define the sample and collection method before comparing results. If the pilot handles simpler matters, its speed should not be compared directly with a previous mixed workload.

The legal engineer’s contribution is the connection across these activities: understand the workflow, make its rules explicit, coordinate implementation, and establish evidence that the service behaves as intended.