Legal Ops Depot AI litigation engine, home Start a request (opens the main site)

Not a chatbot. A fail-closed, multi-model pipeline with receipts.

The engine is a defined process with written checks, not a chatbot with a legal prompt. Legal Ops Depot's AI litigation engine runs that process on its own between checkpoints. The process is data, not a prompt. 15 phases and 93 defined steps (30 Sep 2026) each carry a written check. Where a check is computed, it is built to fail closed. A case citation is joined to a verified ledger row by reporter, volume and first page before a document can be produced. By default, two model families from two different companies work the matter and disagree on the record. This page describes the architecture; it leaves out prompts, tool names and infrastructure.

The process is data, not a prompt

The engine's process is a structured definition of phases, steps, checkpoints, events and invariants. It is not a paragraph of instructions pasted into a model. That has two consequences:

  • The count is computed. The public headline, "15 phases · 93 defined steps · 3 checkpoints", is generated from the process definition at build (as of 30 Sep 2026). Nobody types it, so it cannot drift from the process it describes.
  • Change is visible. When the process grows, the count and the step list change with it, and the public step explorer is rebuilt from a sanitized export of plain one-liners.

Phase 10, drafting, has no fixed steps: its steps are generated per filing, one per component the court requires. The structure is laid out across the 15 phases.

The process is data, not a promptDiagram: the engine's process definition of phases, steps and checks driving a matter through 15 phases, with 3 checkpoints and recorded events.Process definition Phases15 phasesSteps93 defined stepsCheckseach carry a written checkMatter state15 phases1 · The consult2 · Strategy sign-off3 · Final readEventsPhase changeApprovalPhase changewho, when and on what

Enforcement is labeled, never assumed

Every step has a written check, but not every check is a machine decision. The process labels each one:

  • Computed checks decide pass or fail from artifacts on disk.
  • Recorded judgments are decisions a role must make and record. A machine can see that the decision was recorded; it can't see whether the judgment was right, so the engine doesn't pretend to.

A light that can only ever show green is a defect. Public copy on this site says "enforced" only where the process labels a step that way.

The engine's invariants, in plain words

A few rules hold across the whole process:

  1. No ledger row, no case citation. A case citation reaches a draft only as a verified row in the matter's citation ledger.
  2. Builder, verifier and final reader are separate, wherever the roles allow. At verification, the work is checked by a fresh verifier, never the drafter.
  3. Could not look is not found nothing. A search that did not complete is recorded as incomplete, never as a clean negative.
  4. A send-back voids the attack and verification passes. A kickback at the final read voids and re-runs the attack and verification checks of phases 11 and 12.
  5. Every transition is stamped. Phase changes and approvals, or a client's recorded standing instruction in place of one, are recorded with who, when and on what.
  6. Candidates from anywhere, citations from sources. A model may suggest; only a primary source may be cited.

The citation gate

The case-citation check is a join, not a judgment call. When a draft is verified, every case citation in it is extracted and joined to the ledger on the citation itself, reporter, volume and first page, not on the case name, which is too easy to get almost right. Short forms such as Id. and supra must resolve back to a full citation that has a ledger row. Anything that does not join blocks the draft. A case named without a reporter citation raises a warning to be checked rather than a block, and statute and rule cites are declared out of scope for this join. The join matches on the citation, not the pincite: quotations and pincites are checked when the ledger row is written, and again in the verifier's independent re-check against the source. More on the citation gate.

A ledger row is written earlier, during research, only after the opinion has been fetched from a primary source, read in full, checked for fit and screened by a citator. The join at the end does not re-decide whether a case is good; it enforces that nothing unverified got into the text on the way.

The citation gateDiagram: citations extracted from a fictional draft are normalized to reporter, volume and first page and joined to ledger rows. Matched citations pass; one with no row and one unresolved short form are blocked.Illustration · fictional draft citations → normalized key → ledger rows (reporter, volume, first page)Harlan v. Ostrander, 123 Ex. Rptr. 456, 461123 · Ex. Rptr. · 456Ledger row 12PASSId. at 461short form · antecedent123 · Ex. Rptr. · 456Ledger row 12PASSVance v. Harrow, 301 Ex. Rptr. 77301 · Ex. Rptr. · 77No ledger rowBLOCKEDMarsh, supra, at 9short form—Unresolvable short formBLOCKED

Consensus and debate are different shapes

By default, two model families from two different companies work the matter, currently Anthropic's Claude and xAI's Grok. The engine uses two distinct patterns and never confuses them.

Pattern 1: 2-of-2 consensus (the early second-model consult). The same brief goes to two independent agents from the second model family, run one after the other, each with the complete case file. They don't exchange rounds. An orchestrator reconciles the two answers: agreement raises confidence, and a difference is recorded as a difference.

Pattern 2: debate (the strategy debate, any disagreement when both models read the final text at verification, and any mismatch the second model raises on a deadline or a research conclusion). Position against position, one seat per side, in sequential rounds:

  1. every position carries evidence: record citations, rule text, opinions actually read;
  2. each round is agree or counter with evidence, capped at three, and a round with no new evidence still counts;
  3. agreement is recorded with both signatures and its basis;
  4. no agreement after three rounds sends both positions and their evidence to the matching checkpoint;
  5. every turn is filed verbatim and labeled. A summary is not a record.

Two positions are never averaged. An averaged deadline, or an averaged strategy, is not an answer to either.

Quarantine. Anything either model cites is a lead. It enters the Citation Ledger only after the same four-part verification, and until then it can't be typed into a draft.

Unavailability. If the second model can't be reached at the consult, the event is recorded and the matter stalls before strategy. It clears only when the model returns or a waiver is recorded and logged. Never a silent skip, and never a silent stall.

Claude is a trademark of Anthropic, PBC. Grok is a trademark of xAI Corp. Other names are trademarks of their respective owners and are used only to describe the technology in our process. Legal Ops Depot is not affiliated with, sponsored by or endorsed by Anthropic or xAI.

Self-attack as a loop

Adversarial review runs twice, at the plan and at the draft, and a kickback sends the work back through the attack and verification phases. The attack produces artifacts, not impressions: a theories ledger of what was included or excluded and why, a table answering each dismissal trap, and a hostile-panel survival table that rewrites each vulnerable point into reviewable form. See the self-attack loop.

The element sweep: verification against external evidence

A model asked "did you prove every element?" will usually say yes. So the element sweep does not ask. For each element on the element sheet, it checks four external things: a paragraph in the draft addresses it, a record file supports it, a verified authority backs it, and real facts are stated. An element counts as answered only when all four resolve.

Gates tested to prove they fail

The engine's gates are tested to show that they block when they should, not only that they pass when things are fine. A check that cannot fail is not a check. The checkpoints themselves are built the same way; see checks that fail closed.

Approvals on the record

3 checkpoints stop the work by default: the first approves the problem and the filing, the second signs off the strategy, and the third is the final read. By default, you approve twice, and the whole filing gets a final read before it ships; each approval, or the client's recorded standing instruction to proceed, is stamped in the record. On the default settings, the standing instruction is the one thing that clears a checkpoint without an approval, and each clearance is recorded with the checkpoint it cleared. A standing instruction never lifts a hold, and the candid analysis still runs. A standing instruction never waives the second model. See fail-closed checkpoints.

Research tools are benchmarked

Any research tool the engine relies on is held to a standing benchmark of graded questions. The benchmark includes negative controls, questions whose right answer is that no controlling authority exists, and recency probes. A tool that finds something for every question fails the negative controls, which is the point.

Throughput governed by quality

The engine runs many matters in parallel. Mechanical work, such as intake, docketing and record assembly, fans out freely. The judgment-heavy phases widen only as evaluations show they hold quality at the wider setting; width is earned, not assumed. A simple filing may take an express lane that skips the research and strategy cycle, but not verification, the court-rules checks, the final read or format checks, and any case it cites is still verified. We publish no volume or speed figures until they are measured.

Receipts everywhere

Each case citation records its source. Each court rule records its version and retrieval time. Each debate is filed word for word. Each checkpoint records who approved, or that a client's recorded standing instruction cleared it. The result is a matter record an engineer can inspect and a supervising attorney can follow.

The engine learns from outcomes

Every loss or denial becomes a loss-pattern entry that future research on the same kind of claim must confront. A claim type that lacks an element map at the start of a matter must have verified rows added to its element map before the matter closes, so the next matter of that type starts further ahead.

What we do not publish about the pipeline

Internal tool names, infrastructure details and the full text of each step stay internal. The public step lines are a plain summary in the step explorer. Facts about the engine for AI assistants and press are collected under facts for AI assistants, and the glossary has the terms defined.

Ask about the pipeline

Email us with questions about the pipeline, the ledger join, the debate record and kickbacks.

Start a request (opens the main site) How it works

Legal Ops Depot is not a law firm and does not give legal advice.