AI Legal Discovery System

In a civil fraud and asset-diversion case, the other side's strategy was volume: dump thousands of pages of discovery on the opposing team, bank on the review costs running up their client's bill, and bank on the time it takes eating into deadlines. A forensic accountant was retained, but manually cross-referencing 20,000+ pages of bank statements, payroll records, and corporate filings production by production is slow and expensive no matter who's doing it.

So I built a system to do that work faster and cheaper. 17 skills, each reading the state the last one left behind and writing state for the next: one catalogs every production and tracks what's still missing, one transcribes transactions into a verified ledger, one applies forensic judgment to flag what's suspicious, and eight more are tuned to the specific documents a fraud case produces. The output fed directly into motions to compel, sanctions filings, and the report that helped secure a preliminary injunction.

The system is built as a pipeline: each skill reads the state the previous one left behind, then writes state for the next. On intake, it generates a short case brief and a six-file wiki — entities, timeline, claims-to-evidence mapping, gap tracker, proceedings log, and conduct index — so the matter stays oriented across months without bloating context on every run.

Every new production is logged, inventoried, and diffed against what's still outstanding. Gaps get permanent IDs that never reset, so "what are we still missing from the other side" has one authoritative answer even six productions in. Gaps aren't just marked found and forgotten either: each one is tracked as filled, partially filled, or still missing, and gets rechecked every time a new production arrives, so the tracker can't quietly go stale while the case moves on around it. Transactions are transcribed from bank and credit card statements into a verified ledger, with low-confidence reads flagged instead of guessed and duplicates caught across overlapping productions. No judgment happens at this stage; the goal is accuracy only.

Once the ledger is human-verified, a forensic analysis layer categorizes every non-authorized transaction — personal, related-party, unauthorized compensation, asset transfer, suspicious — each with a court-ready confidence tier. It refuses to run if the underlying ledger hasn't been verified, so errors can't compound silently downstream. If a classification gets corrected here, the system knows the downstream category tabs are now out of sync and prompts a resync, rather than leaving a stale version sitting next to the corrected one. Finally, eight specialized analysts (payroll, tax, corporate records, contracts, communications, general ledgers, assets, and litigation records) compare what the books say happened against what the bank records actually show for the same period. The gap between the two is usually where the case lives.

1. 1

   Client dollars go further.

   Review time that used to run up hourly billing gets automated, so clients pay less for the same or better result.

2. 2

   It's a competitive edge, especially for small and solo firms.

   A firm that can credibly say it processes discovery faster and cheaper than the competition wins more cases, particularly against larger firms with bigger review teams.

3. 3

   It protects the litigator's own bandwidth.

   A solo litigator running several cases with one paralegal doesn't have slack time. When opposing counsel produces evidence with a short statutory response window, days spent locating the right document in an unreviewed production are days not spent writing the response.

4. 4

   It strips the advantage from the document-dump tactic itself.

   Producing an oversized document dump is a bet that it costs the other side more in time and money to review than it cost to produce. When review is fast and cheap, that bet doesn't pay off.

17 skills span intake through damages and discovery audit. The output drove motions to compel, sanctions filings, and the report used to secure a preliminary injunction. 

This system doesn't supersede the need for a forensic accountant. A true accounting of damages — the kind that holds up in court and informs settlement strategy — still requires a trained forensic professional.

What it does well is produce a preliminary analysis that helps the team understand the scale and scope of the financial malfeasance early, and in some cases that analysis can be used in preliminary motions. In this case, the team was able to reconstruct the movement of funds from one set of entities to the other cleanly, and the charts and tables the system generated were used in court to help secure the temporary injunction.

I built this as a plugin in Claude Cowork and iterated through the workflow in conjunction with the litigation team, but because I was the one running it I was able to adjust which model I used for which task.

Turning it into something other litigation teams could use raises different questions. In it's current form, I would have to provide specific guidance on which models to use for which task, and when to encourage the model to spin up subagents. I'm also more familiar with where this tends to break and when to double check its results than your typical litigator would.  A real product would need a proper UI: upload a production, watch it get cataloged and flagged without narrating the process back to a chat window. It'd need per-matter data isolation and access controls, since discovery is privileged and confidential by nature and a shared system can't leak one client's case into another's. And it'd need the confirmation gates built into actual review screens; a paralegal approving a batch of flagged transactions shouldn't have to read a chat transcript to do it, they need a queue they can click through.