The legal engineer's journey

A legal engineer's work has a recognisable shape. It starts with a lawyer describing how something is done today, and it ends with a better process that people use on real matters, which then teaches the team what to improve next. The toolkit encodes that shape as a meta-skill and a workflow, so that following it means doing the core of the job.

View the relationship model

flowchart TB
    subgraph L3["LAYER 3 · DESIGN WITH THE LAWYER"]
      A["1. Listen<br/>The lawyer's account of the work"] --> B["2. Model<br/>As-Is · issues · To-Be · each step's need"]
      B --> C{{"3. Design sign-off<br/>Process owner"}}
    end
    subgraph L2["LAYER 2 · DELIVER"]
      D["4. Resolve<br/>Reuse · wrap · build each capability"] --> E["5. Build and test<br/>Backlog · every route exercised"]
      E --> F{{"6. Release sign-off<br/>Exact blueprint hash"}}
    end
    subgraph RUN["IN USE · LAYER 3 CALLS LAYER 1"]
      G["7. Run matters<br/>Launcher · inputs · tasks · human decisions"] --> H["8. Learn<br/>Feedback and outcomes"]
    end
    C --> D
    F --> G
    H -.->|Next version| B

1. Listen

The journey begins with the person who owns the work: a partner, a general counsel, a team lead. They describe how a matter actually moves today, including the workarounds and the parts nobody owns. The legal engineer treats this as evidence, not as a specification. Instructions inside documents stay evidence; they are not commands.

Produced: the consultation narrative and any supporting documents.

2. Model

With the process-modelling meta-skill, the legal engineer turns the account into an As-Is model, analyses issues from symptom to root cause, and proposes a To-Be process. Each step that an AI capability might perform is stated as a need: what it must produce, from what inputs, with what evidence for a reviewer, and who decides on its output. The design describes the process the lawyer needs, not the one the available tools happen to support.

Questions that change routing, authority or legal criteria go back to the process owner. Nothing is invented to fill them.

Produced: a draft manifest, the issue analysis, a briefing with open questions, and a resolution record listing every need as pending.

3. Design sign-off

The process owner reviews the models and confirms the design. Their name, their confirmation and the draft's hash are recorded. Delivery does not begin before this.

4. Resolve

Now the question becomes how each need will be met. The legal engineer inventories what the domain library actually offers, then for each need:

• reuses a reviewed binding where one fits;
• wraps an installed skill's existing method where it fits but has no binding;
• builds a new method only when nothing fits, with its legal rules taken from research, a playbook or the owner, never from a model's memory;
• or leaves the need unresolved, keeping the dependent work out of the release.

Produced: a capability resolution record listing the candidates considered and the choice made for each need.

5. Build and test

Wrapped and newly built capabilities, human gates and recommendations become backlog items with acceptance criteria. The team exercises every route of the compiled workflow with synthetic inputs: approval, rejection, missing tools, rework and the cap on rework.

Produced: a tested workflow version and the evidence of its tests.

6. Release sign-off

The process owner approves the exact compiled version, identified by its blueprint hash. Releasing installs a launcher: a skill named after the workflow, which lawyers can start by asking for it in plain language. Released versions are never changed; improvements become new versions.

7. Run matters

A lawyer unfamiliar with the toolkit may request an entire agreement clause for a supply contract. The launcher gathers the matter inputs, starts a run on the released version in a separate matter folder, and carries out each task with the named skill. Each required decision is referred to the designated person, whose answer is recorded. The launcher does not decide on that person's behalf.

8. Learn

At the end of a matter, the lawyer is asked what should change. Rejections, rework and feedback are evidence for the next version, which starts again at the model. Matters already running stay on the version they began with.

Why this is an entry gateway

The journey asks for each competence in the proposed standard: understanding legal work and its authority, modelling a process, specifying and testing capabilities, coordinating delivery, and operating a system responsibly. A newcomer who follows it performs the role's central loop with guardrails in place: the sign-offs cannot be skipped, unsupported claims are refused, and the evidence is kept. An experienced practitioner can use the same structure to make their judgement inspectable.

What has been exercised so far

Fresh AI sessions, given only a consultation narrative, have carried the journey through stages 1 to 3 on a synthetic drafting project. They invoked the toolkit and process-modelling skills, recorded every need as pending, and stopped for the design sign-off instead of inventing answers. The release step has been tested, including its refusals. A complete live matter, from launcher to the lawyer's final decision, has not yet been run; that is the next piece of evidence the project needs.