A litigation partner at an Am Law 50 firm told us last month that his team had just reviewed 400,000 documents for a single motion. The review took eight weeks, cost $2.1 million, and found 147 responsive documents. When I asked if he thought there were more responsive documents in the set, he said "probably"—but the budget was gone and the deadline had passed.
This is not an unusual story. Document review in complex litigation has become an industrial process: upload documents to a platform, train associates and contract attorneys on relevance criteria, review in batches, escalate edge cases to partners, produce the set, and hope nothing critical was missed.
The process is expensive, slow, and—most importantly—it does not actually solve the problem. The goal of discovery is not to review documents. It is to understand what happened, who knew what when, and whether the evidence supports your theory of the case. Document review is a means, not an end.
Why semantic search is not enough
The legal tech industry has spent the past five years building semantic search tools for discovery. These tools use embeddings to find documents that are conceptually similar to a search query, even if they do not share exact keywords.
This is useful. It helps you find the email where the CFO writes "we need to be creative with the numbers this quarter" even if your search query was "accounting fraud." But it does not help you answer the questions that matter: How many times did this happen? Who else was involved? What was the timeline? What were the dollar amounts?
To answer those questions, you need structured extraction. You need a system that can read 400,000 documents and produce a table that says: these are the fifteen people who discussed revenue recognition between Q2 and Q4 of 2023, these are the thirty-two emails where they used hedge language, and these are the eight documents where specific adjustments were proposed.
What structured extraction looks like in practice
We built Clad to do exactly this. The system takes an unstructured document set—emails, contracts, presentations, spreadsheets—and extracts structured data according to a schema you define.
For a contract dispute, the schema might be: party names, contract dates, payment terms, amendment history, breach allegations. For an employment case, it might be: complaint dates, complainant names, alleged conduct, witnesses, remedial actions taken.
Once the data is extracted, you can query it like a database. Show me every document where Person A and Person B discussed Topic X between Date Y and Date Z. Show me all contracts where payment terms were modified after signing. Show me every complaint that was escalated to HR but not to legal.
This is not hypothetical. We have run this process on datasets ranging from 50,000 to 3 million documents. The extraction accuracy—measured against manual review—is consistently above 94%. The time savings relative to traditional review is typically 60-80%. And the cost savings are even larger.
The human-in-the-loop question
Every legal team we work with asks the same question: can we trust the extraction, or do we still need to review everything manually?
Our answer: you need a human in the loop, but not in the way you think. The human's job is not to review every document. It is to review the extraction schema, validate a statistical sample of extractions, and flag systematic errors that need to be corrected.
This is fundamentally different from document-by-document review. Instead of asking "is this document responsive," you are asking "is the system correctly extracting the pattern we care about." The latter question is answerable with a 2% sample. The former requires reviewing everything.
— Henry