In daily use · Los Angeles
Engineering documentation · the architecture
The System / architecture reference

This documents the system that does the work: small single-purpose agents, composed into fixed pipelines, checked by a separate gate, handed off through written contracts.

Not a product tour. This is how the machine is built and why it is built this way, the decision behind each part and the alternative it rejected. The short version lives on How it works; the run lives on See it work. This page is the depth underneath both. Built and run independently by Jaden Van, a paralegal, in daily use inside a California criminal-defense practice in Beverly Hills, where it supported a federal trial. The client firm's own attorney reviews and signs every deliverable.

01 What it is

One shape, four decisions. The architecture reads on a single line.

A single general-purpose assistant cannot be checked, because there is no fixed spec for what it was supposed to do. This system is built the other way: the work is broken into small jobs, run in a fixed order, and checked by something that did not do the work. Here is the whole shape, then the four decisions that produced it.

From
The firm's systems
email, files, the calendar, the court record
→
Small workers
Agents
one job each, run in parallel
→
In fixed order
A pipeline
the same steps, every time
→
Draft
Work product
built, not yet trusted
→
Checked by
The gate
reviewers who never saw it written
→
To
The attorney's desk
for judgment, and a signature
Decision one

Small single-responsibility agents, not one big agent

Each agent does one narrow, checkable job, and nothing else. It reads discovery, or it checks citations, or it profiles a judge. A worker with one job can be verified in isolation and reused in parts. Small jobs are checkable jobs.

The alternative rejected: a do-everything agent with all the tools. It cannot be tested, because you can never say exactly what it was supposed to do, and it cannot be reused in parts.
Decision two

Fixed pipelines, not improvised chains

A pipeline is a set sequence. In law the same task needs to run the same way every time, and you need to know where it is when it fails. The order is where the judgment lives: facts are pinned before prose, strategy is approved before argument, citations are checked before the pour.

The alternative rejected: an agent that re-plans its own steps each run. It demos well and is unsafe on a filing, because quality becomes a coin flip on the order it happened to pick.
Decision three

A separate verification gate, not self-checking

Between the draft and the desk sits a set of reviewers that never saw the draft written, reading the source documents the drafters never opened. A fresh-context reviewer is the only thing that catches a confident, finished, wrong document. Section 05 shows the day it did.

The alternative rejected: a generator that reviews itself. The reasoning that made the mistake shares the blind spot that hides it.
Decision four

Written contracts between agents, not shared memory

Agents hand off through standard documents, the same artifacts a human team hands each other. An agent has no memory of the conversation, so the handoff has to carry everything: the task, what done means, and how to hand the result back. Section 04 is that story.

The alternative rejected: a shared memory any agent can read and write. A store any agent can write is a store any agent can poison.
02 The bench

The agents, grouped by what they do.

Every example output shown in these cards is invented: names, charges, dates and docket numbers are built for illustration and match no real person or matter. The behaviour is the real behaviour.

Each agent is a single-responsibility skill: a spec, an implementation kept to the standard library, and a canonical test. The bench is not fixed. A new agent is authored by hand and dropped into the same form as the rest, which is what lets a firm's own workflow become one more worker. Click any card for what it does, how it works, and where it stops.
Research & record
Matter researchcase-researchPulls one matter's full state from every firm system into a single brief.
Fact ledgerfact-ledgerThe source of truth for a case. Every fact validated before it is written.
Case chronologychronologyBuilds the dated timeline of events from the record.
Sample miningsample-miningFinds the firm's best prior version of the document you are about to write.
People & adversary
Person intelligenceperson-intelligenceProfiles a judge, a DA, an officer, down to financial disclosures for recusal.says INSUFFICIENT DATA, never guesses
Adversary modelingadversary-modelingPredicts a named DA's and the judge's attack, then pre-writes the rebuttal.every forecast tagged as prediction
Drafting & format
Pleading pourdocument-pourPours finished text onto California pleading paper, the firm's own template.
Outbound emailoutbound-emailsDrafts the external email or letter in the firm's voice. Never sends on its own.
Client redactionclient-redactionBurns in victim and witness PII to make a client-safe copy of discovery.
Format scrubformat-scrubCatches stale firm identity and stray formatting before anything ships.
Court form fillpdf-form-fillFills the court's PDF forms, fields mapped, no retyping.
Court operations
Calendar read/writemaster-sheet-rwReads and writes the firm's master calendar, the one source of dates.
Filing channelfiling-channel-lookupKnows how each court and case type actually wants the filing made.
Examination prepexamination-prepBuilds the witness examination outline, cross or direct.
Verification
Citation verifiercitation-verifierChecks every citation against the public record. Extraction runs on the machine.
The verification gatepre-delivery-verifierDispatches the six automated reviewers before anything reaches the desk.
Click any agent to open what it does, how it works, and where it stops.
+ one, for setup cold-start-interview configures the whole system to a new firm on day one. It does setup, not case work, so it sits apart from the case-work bench above.
03 The pipelines

Eight finished jobs, each a fixed run of those agents that ends in the gate.

Each pipeline declares an autonomy tier, the badge on every card. It sets where the operator's time goes, not whether high-stakes work is verified. AUTO is internal and reversible. BATCH is staged and reviewed before it leaves. GATE is filed, signed, or served, and always runs the full verifier plus attorney sign-off. Click a card to step through its phases.
motion-pipelineGATE
Draft a motion, end to end, on pleading paper.
halts for the strategy
open the run ▸
discovery-audit-pipelineAUTO
Turn a discovery dump into a defense-ready audit memo.
open the run ▸
discovery-response-pipelineGATE
Respond to served discovery: interrogatories, admissions, production.
halts for the narrative
open the run ▸
hearing-snapshot-pipelineAUTO
One page of prep for an upcoming hearing, everything at the podium.
open the run ▸
remote-appearance-pipelineGATE
Get a client approved to appear remotely, forms and cover letter included.
open the run ▸
matter-intel-daily-brief-pipelineAUTO
The morning brief: today's calendar, what is urgent, what ran overnight.
open the run ▸
ebpace-billing-pipelineAUTO
Walk the county billing portal, field by field, from a minute order.
open the run ▸
matter-open-pipelineBATCH
Open a new matter and stand up its file the firm's way.
open the run ▸
A design decision worth seeing

The drafting pipeline halts for the attorney's theory. But the halt sits after research, not before.

A drafting pipeline never writes a sentence of argument before the theory of the case is approved, a hard stop. The placement is the interesting part. The halt comes after research, samples, and the adversary forecast have run, so what the attorney approves is a real, research-grounded strategy, not the model's opening guess. There are two separate gates: the cheap up-front choice, motion type and scope, at triage, and the substantive one, the theory, once there is something real to approve.

The alternative rejected: a strategy gate before research. It produces a generic prompt that quietly anchors the attorney into validating the model's framing. Placing it after research is a decision about human anchoring, not just workflow.
What it reads from

It works inside the systems the practice already lives in.

Gmail The master sheet Drive Dropbox discovery CourtListener Court portals
Any system already in use is wired to by its API or connector, and the connector is built where one does not exist yet. Some case-management systems have no off-the-shelf connector today. That is a build, not a wall.
04 The handoff contract

The one constraint that shaped everything: an agent cannot stop to ask a clarifying question.

A system of independent agents has the same problem a team of people has. A worker with no memory of the conversation cannot pick up another's work without a written contract telling it what to do, what done means, and how to hand the result back. The difference from a human team is the one that made the documentation strict: an agent cannot pause and ask, so the document has to be complete, or the handoff fails.

The interface, one representative example

Every worker hands back the same typed slip. No worker is allowed to pretend.

A pipeline dispatches an agent with a self-contained brief and gets back one typed envelope, the same shape for every agent, the agent's own result riding inside an opaque data field. The form forces an honest answer: it worked, it did not have enough to go on, or it errored.

Status is outcome, not quality. There is no fourth option where a worker guesses and reports success. A failure reports as a failure, rather than arriving as a confident answer. That one choice is the safety spine.

{ "schema": "dispatch-envelope/v1", "status": "ok", // ok · insufficient_data · error "summary": "Ellison: 1 case, prelim set, 2 open gaps", "data": { … }, // the result; shape known to the caller "sources": [ … ], "issues": [], "error": null }
The other standard structures, the same idea in different shapesnamed here, not specified
dispatch brief
The self-contained task handoff to a fresh agent: role, read-first, method, deliverable, validation target. It also carries governance, every fix is a proposal routed for approval, never applied on its own.
sign-off package
The completed build handed back: what changed, prerequisites verified, file map, before-and-after evidence, rollback. The reviewer approves without reconstructing anything.
change record
How a fix enters the system, with its validation target and rollback attached. Section 06 is this one in motion.
design spec
How a change is thought through before building: current state, gaps ranked by severity, the design, build order, and an explicit what it deliberately does not do.
05 The gate

The reviewers never saw it written. And they read the source the drafters never did.

The terminal check every high-stakes output passes before a person sees it. The agents that wrote the draft can all agree with each other and all be wrong together, so a separate gate of reviewers checks the finished draft, each with no memory of how it was written, each applying one rubric. Six automated reviewers run on a filing, two on an internal draft.

citation
Every cite, against the public record.
reads · the draft
factual-recital
Charges, counts, enhancement scope, dates.
reads · the charging papers
completeness
Every required section present.
reads · the draft
procedural
Filing channel, signer, service math.
reads · the draft
format
Pleading format, typography, firm identity.
reads · the draft
voice
House writing rules, no machine tells.
reads · the draft
Five of the six can pass a document that is uniformly wrong, because they only ever read the draft, and the draft agrees with itself. The sixth reads the Information the drafters never opened, and reconciles every charge, count, enhancement, and date back to the source paper. A document can be internally consistent and still wrong about the case, and only the source can tell.
▲ the day it caught a finished filing

A felony filing, marked finished and ready, carried four defects no internal check would surface, because an internal check only compares the draft to itself.

01A blank declaration where sworn facts were supposed to be.
02A sentencing enhancement scoped to every count, when the charging document attached it to two.
03An incident date that did not match the charged conduct.
04A service email addressed to the wrong recipient.
Five of the automated reviewers passed it. None of them read the Information. This one read the Information.
A real matter in the firm's active caseload. The client name and case number are not shown, for the same reason every other example on this page is a built case. The defects, and the catch, are exactly as they happened. No invented statistics.
why the check stays honest

Each reviewer runs with its write tools removed.

A reviewer is dispatched with no drafting memory and cannot mutate anything, it can read and report only. A reviewer that could quietly fix things would hide the exact defect you wanted surfaced. Read-only is what makes the check honest. A known defect blocks delivery; it is never downgraded to clean-up-later.

six automated reviewers · run in parallel, then joinverdict = worst present
definition of done

Done is a condition a machine can check, not a feeling that it looks right.

The redaction test is one instance of the rule: re-render at 300 DPI, OCR the pixels, search for every protected name, and if any returns, it failed and rebuilds. Every definition of done in the system is a machine-checkable condition, which is what lets the gate be strict without a human in the middle of every step.

11 citations · verified liveCourtListener
06 The loop

A failure on a live matter is fixed at the class, not the instance, and locked as a test that runs on every release.

When something goes wrong on a real case, it is abstracted to a fault class, fixed at the source, and logged with a validation target that proves the fix worked and a rollback that undoes it. An append-only log holds shipped changes; a lifecycle queue holds pending ones. Nothing is silent, nothing is lost. The failure this replaced was improvement notes dying in a chat that ended before anyone acted.

It happens
A correction
a miss, a wrong call, a thing the attorney fixes by hand
→
Same day
Logged with a target
written down with proof of what fixed must mean, and a rollback
→
Then
Fixed at the class
the rule, the pipeline, or the template, not a one-off patch
→
Forever
Frozen as a test
the exact failure, locked into a set that re-runs
↺ The lesson returns to the system, so the next draft, and every draft after it, is held to it. Patching one document leaves the same bug in every other case.
the worked example

A template hardcoded a court venue instead of reading config. Invisible for months, because every matter was in that county.

Then a new-county matter mis-captioned. It was caught by the verifier, not the generator, fixed as a class by parameterizing every venue, and validated two ways: the original re-rendered byte-identical, the new county came out correct. Rollback was five minutes. That single incident is verification catching what generation missed, a class-not-instance fix, and a traceable, reversible change, all at once. The design spec for this loop even has a before-and-after: it first read single-writer, no concurrency concerns, until a real lost-update bug forced an optimistic-locking rewrite. The documentation evolves in response to incidents.

capture · one

An enforced rule

The correction becomes a rule an independent reviewer checks on every future draft. Not a note someone has to remember. A gate that runs.

capture · two

A frozen regression case

The exact failure is locked into a test set that re-runs, so it cannot come back quietly. If it ever reappears, the test fails loudly.

capture · three

A reusable sample

The corrected work becomes the template the next draft is mined from, so the improvement spreads to new matters instead of staying on one.

19of 19, last full run
Nineteen cases sit in that test set, and every one is seeded from a real thing that went wrong here, not a synthetic benchmark. The filing defect from the section above is the first case in it. It is caught by a locked test on every run after it.
Honest mechanics: 12 of the 19 run by script in about a minute; the other 7 are dispatched by hand, because they test judgment and cannot be reduced to a checklist. It is a real, re-runnable regression set, not a one-button CI suite.
07 The foundation

Under the agents sits the layer that keeps the system legible to itself.

The bench and the pipelines are the visible machine. Underneath is the part an enterprise cares about: how the system stays lean, routes to the right source, and enforces its own governance with tooling instead of discipline.

the kernel

One file, loaded every turn, deliberately lean

The kernel holds only what must fire every turn: identity, hard constraints, the always-on directives, the routing table. Everything else lives in topic docs loaded on demand. An always-loaded file that grows unbounded buries its own most important rules, so keeping it lean keeps the safety-critical ones at highest attention. That is progressive disclosure as a safety choice, not a tidiness one.

the retrieval playbook

A source-routing table, including the sources that do not answer

Each need maps to the one source that answers it, and explicitly to the ones that do not. The wrong source is a silent detour that wastes a session, so the playbook names the right door and closes the wrong ones.

registry validation

Governance as tooling, not as discipline

A deterministic validator runs at install and on any change that touches the registry: name collisions, missing dependencies, status drift, trigger overlap, oversize metadata. It converts everyone remembers to update the registry from a convention into an enforced check that must pass. This is the clearest artifact of building governance in rather than relying on people.

the health pass

The improvement loop pointed at itself

A read-only self-diagnostic runs on a cadence over the kernel, the queues, the logs, and the registry. It produces a dashboard of signals with thresholds and a ranked list of findings, so drift is surfaced before it becomes a defect.

Data handling, as architecture
  • A draft is never uploaded to check its citations. The text is read on the machine, and only the list of citations leaves it for verification.
  • Files are never used to train any model. The tools run under terms that forbid training on the data.
  • It wires into the systems already in use. The work happens in the firm's email, drive, and case files by connector, not by copying everything into a separate product.
  • Redaction verifies its own output. Every client copy is re-rendered, OCR'd, and searched for any protected name that survived.
These four are properties of how the system is built and can be checked directly. Confidentiality and deletion-on-request are made binding by the signed Confidentiality and Data-Handling Commitment, not asserted here. One person, with a name, is accountable for the work.
Boundaries, said plainly
The architecture ports across firms. It is not drop-in.
The pipelines, the verifier, and the gate are shared and reused. Day one rebuilds the config file and the sample bank to a new firm through a guided interview. Until that parameterization lands, the pleading template still carries firm-specific identity, so a new firm is a setup, not a switch.
The trial tier is bespoke, scoped per engagement.
It is not a packaged pipeline. It is two ported primitives, chronology and examination-prep, plus a hand-built case war room, assembled from the same bench for one trial. In a federal trial it red-teamed the defense's own opening and mapped every factual promise to its source and its witness. The trial that is real is under a protective order and cannot be shown; what appears elsewhere on the site is a built case of the same patterns.
Two primitives are adapted, not original.
chronology and examination-prep are adapted from Anthropic's open claude-for-legal skills and rebuilt around the firm. The rest of the bench is original. The claim is what runs, not who wrote the seed.
08 Next

Watch it run, read what it produces, or point it at your practice.