The loop / the part a prompt can't do

Four things a prompt cannot do.

The question under every AI pitch is whether it is a clever prompt that will confidently hand you something wrong. Here is what this system does that a prompt does not: it knows what is yours to decide, it checks its own work against the record, it logs every fix as a permanent test, and it drafts the other side's response. It is how the system runs today, inside a working criminal-defense practice.

01 It only gets better, and it shows its work

Every failure it hits once becomes a permanent test. This is the log.

Train a person for a year and the learning is theirs; here, every correction is captured three ways and mechanically re-checked. The log below is the actual one, most recent first. Locked cases re-run at every recheck, and no case is removed to make a run pass.

running 19 locked cases 12 by script · 7 by hand every locked case re-runs on each release, and none is removed to make a run pass
2026-06-08
case 03
A pour drifted on italicization and spacing against the firm's format standard.
→ the format reviewer now checks the rendered page against the standard before it is called done → locked.
2026-06-07
cases 01 / 04 / 05
One near-final felony filing carried a blank declaration, an enhancement mis-scoped to all counts, a wrong incident date, and a displaced proof-of-service email, defects no internal check surfaced because the drafters never read the charging document.
→ one incident, three lessons: added the factual-recital, completeness, and procedural reviewers → each locked as its own regression case, re-checked on every pour.
2026-06-06
case 09
On a trial matter, a cloud-only discovery file was missed by a local-only search, which would have understated a production.
→ the audit now confirms a file has real content before it calls a file present or missing, and says exactly how to hydrate it → locked.
2026-05-19
case 06
Identity drift: a wrong bar number and a stale template value could leak from one matter into another's output.
→ firm-identity constants are injected and audited on every pour; a wrong value halts the batch → locked.
2026-05-17
case 02
A hearing date on a filing did not match the court's docket, and the clerk rejected the filing three times.
→ a pre-filing reconciliation now confirms the hearing against the docket before anything is keyed to it → locked.
+ the rest of the set, including seven known-good comparators: real, accepted filings the checks must never flag. Cases are added when a live defect reaches a human, and never removed to make a run pass.
Every entry is redacted to the failure class, never the matter. The same discipline your files would get: the system logs what it learned, not whose case taught it.
a real failure
Friction
something goes wrong once, on a live matter
→
named + fixed
A patch
with a validation target, not a quiet edit
→
frozen
A locked case
added to the regression set forever
→
re-checked
Mechanically
the same failure is caught by a test on every run after it
02 It argues the other side, first

Before you file, it plays the prosecutor. It tells you how the other side will attack, and pre-writes the answer.

This is the part that does not look like a text generator. Pointed at the suppression motion from the run, it models the DDA's likely opposition against the record, ranks each move by how likely it is, and drafts your rebuttal to each. Every forecast is tagged as a prediction, never a fact, so you weigh it, not trust it.

adversary-modeling · People v. M. Ellison · motion to suppresspredicted opposition, not fact
DDA Pryce will argue inevitable discovery: the fentanyl would have been found in a lawful inventory search after impound.
likelihood70%
Pre-written rebuttal. No inventory policy is in the record, and the console search began before any arrest or impound decision (Ex. C, BWC 02:11:07). Inevitable discovery cannot rest on a hypothetical the People never established.
DDA Pryce will argue the K-9 alert supplied probable cause for the search.
likelihood45%
Pre-written rebuttal. An alert cannot justify a search that preceded it. The CAD log fixes the K-9 unit's arrival at 02:14:22, roughly three minutes after the console search began (Ex. C BWC 02:11:07 vs. Ex. D CAD #011).
DDA Pryce will dispute the body-camera timestamp as imprecise.
likelihood30%
Pre-written rebuttal. The roughly three-minute gap is on the face of the file at confidence 0.96, and the sequence, not the second, is what forecloses the alert as after-the-fact justification.
The same engine profiles the assigned judge's prior rulings on the issue. Forecasts are confidence-tagged and left for your judgment. Built case; the modeling is real pipeline behavior.
03 It knows what is yours to decide

It knows where its job ends. Written into the pipeline, not promised.

A chatbot does whatever you type. This one decides how to work before it works, and the line between its job and your judgment is explicit. Three ways, all running today.

the judgment layer
It halts for your theory. On a motion, the pipeline stops at a strategy gate and writes no argument until your theory of the case is in. It sharpens the theory you give it; it never invents one for you.
Depth by method, not persona. It is never told to "act like a brilliant lawyer", which only inflates confidence, and a reviewing attorney who catches one confident bluff distrusts everything after it. Instead every assertion is bound to a citation it verified. The work is rigorous because the method is.
It hands you the holes. The audit surfaces the weak points in your own case, the gaps, the thin authority, the "confirm this before you rely on it", plainly, not a flattering memo.

The licensed judgment stays with your firm. The system prepares the material; you make the call.

04 It fails its own finished work, on purpose

The defense against a confident, finished, wrong document is structural, not a promise to be careful.

An automated six-reviewer gate checks every draft against the record before you see it. Five can pass a document that is uniformly wrong, because they only read the draft. The sixth reads the operative pleading the drafters never reopened. Pointed at motions this firm had already filed, the gate caught real defects the earlier checks had missed. It is the system failing its own finished work, on purpose, before it reaches you.

citationfactual-recitalformatcompletenessproceduralvoiceyou are the last line

Watch a gate run in the live catch →   See how it is tested →

05 It is built for your firm, not sold by the seat

Small single-purpose workers, composed into your pipeline through one strict contract.

A do-everything assistant cannot be checked, because you can never say exactly what it was supposed to do. This is the opposite: each worker has one job and hands the next a small, strict envelope that says done, not-enough-data, or error, and nothing else. That discipline is why a new pipeline can be built for your workflow and still be verifiable from the first day.

The one piece of engineering worth showing a lawyer

Not code you have to read. Just the shape of how the workers talk to each other: a worker never guesses. It reports exactly what it has, or refuses and says why. That refusal is the whole safety story in one object.

// every worker returns the same envelope{ "status": "ok", // ok | insufficient_data | error "result": { ... }, "sources": [ "Ex. C BWC 02:11:07" ], "confidence": 0.96} // when it cannot be sure:{ "status": "insufficient_data", "missing": "CAD log not produced" }
The bench you can see is what this firm's work called for. The offer is the same method pointed at your practice: name the job that takes your week, and I build the worker for it.

A wrapper can be copied in a weekend. A system that polices itself and argues the other side cannot.

A product ships once and stays what it is. This one keeps being extended, with your firm deciding what gets built next.

The fastest way to check any of this is to watch it run on a file you know cold. The first one is free.

▶ Send me one file Open the hood, the full system