Legalcare
Sign in
All posts
Product · 10 min read

Compiling workflows: turning intent into an executable plan

How we let counsel describe a process in English and get back a versioned, testable graph.

One of the quiet superpowers inside LegalCare is something we call the workflow compiler. It takes a description of a legal process, written in ordinary English by a practicing lawyer, and turns it into a versioned, testable graph that the system can actually run.

This post is about why we built it that way, and what it took to make it work.

The problem: legal processes don't fit in code

Ask an engineer to model "a trademark filing" and you'll get a flowchart. Ask a trademark attorney to describe the same thing and you'll get a story, full of "unless", "depending on the examiner", and "if the client comes back with…".

Both descriptions are right. They're describing the same reality at different resolutions. The compiler exists to bridge them.

What lawyers actually write

A counsel partner writes something like:

"Start with a knockout search. If anything material comes back, pause and email me before continuing. Otherwise draft the goods/services description, route it for my review, and once I sign off, file and put a 6-month reminder on my calendar."

That's the spec. We don't ask them to draw boxes. We don't ask them to learn YAML.

What the compiler produces

From that English, the compiler emits a graph that looks roughly like this (simplified):

workflow: trademark.standard
version: 12
nodes:
  - id: knockout_search
    skill: tm.knockout_search@3.1
  - id: triage_results
    type: branch
    condition: knockout_search.material_hits > 0
    on_true: pause_for_counsel
    on_false: draft_gs
  - id: pause_for_counsel
    type: human_checkpoint
    notify: counsel.email
  - id: draft_gs
    skill: tm.draft_goods_services@2.4
  - id: counsel_review
    type: human_checkpoint
  - id: file
    skill: tm.file_application@1.8
  - id: schedule_reminder
    skill: calendar.schedule@1.0
    args: { offset: "6 months" }

That graph is versioned, diffable, and testable. We can replay it. We can run it against historical matters. We can show a partner exactly what changed when v12 became v13.

Why we didn't just use a workflow library

We tried. Off-the-shelf workflow engines (Temporal, Airflow, n8n, every BPMN tool ever made) assume the author is an engineer. They optimize for retries, durability, and observability, all things we needed, but the authoring surface is hostile to lawyers.

The compiler isn't a replacement for those engines; it sits on top of one. The novel part is the front half, going from prose to plan, not the back half of executing the plan.

The hard part: ambiguity

English is ambiguous. "Email me before continuing", me who? "6-month reminder", from filing date or from today? "Material hits", defined how?

We resolve ambiguity in three ways, in order of preference:

  1. Conventions. If the workflow is in the trademark domain, "material" has a default definition. The compiler uses it and tells the author what it assumed.
  2. Clarifying questions. If the ambiguity is high-stakes (anything involving deadlines, money, or scope of authority), the compiler refuses to emit until the author answers.
  3. Explicit escape hatches. For genuinely fuzzy steps, the author can declare a human checkpoint and move on. Better an honest pause than a confidently wrong automation.

What this unlocks

Three things, mostly:

  • New workflows in hours, not sprints. A senior associate can describe a new matter type before lunch and have it running against real intake by the afternoon.
  • Auditable change control. Every workflow has a version, an author, and a diff. Partners review changes the way engineers review pull requests.
  • Transferable expertise. When a great attorney encodes how they handle a kind of matter, that knowledge stops being trapped in their head. Other lawyers, and LEA, can run it.

What's still hard

Loops are hard. Long-running matters with months between steps are hard. Workflows that span multiple jurisdictions with different procedural rules are really hard. We have answers for some of these and honest gaps in others. We'll write about both as we go.

If you're a practitioner who's ever wished your firm's playbook was something more than a Word document on a shared drive, we'd love to talk. That's exactly the problem the compiler was built to solve.

Talk to us