Sanjay K Mohindroo
Rethinking What AI Should Actually Do for Litigation
A litigator I once spoke with described the worst moment in any case this way: it isn't the day you lose an argument in court. It's the day, often late in preparation, when you realize there's a question about your own case that nobody ever answered, and you have no way of knowing whether opposing counsel already has.
It's rarely because anyone hid anything. It's because a real case file isn't a handful of documents you can hold in your head. It's thousands of pages: pleadings, emails, messages, financial records, scanned exhibits, witness statements. Somewhere in that volume, a question sits unasked.
Not what does this document say?
But what haven't we looked for yet?
That distinction is the starting point for a system I've been designing, and it's why I think there is still an important problem for legal AI to solve.
The limits of the "answer machine"
Today's legal AI tools can do remarkable things. They can search enormous document sets, summarize depositions, identify clauses, build timelines, help draft submissions, and surface information that would otherwise take hours to find.
But many of those workflows still begin in the same place: with a question the lawyer already knows to ask.
"Summarize this deposition."
"Find every clause referencing termination."
"Show me communications between these two people."
"Draft a response to this motion."
The system may answer extremely well. But the interaction remains largely reactive.
In litigation, that is a narrower kind of help than it first appears.
Cases are not always weakened by a document nobody read. Sometimes they are weakened by a document nobody thought to go looking for, a contradiction nobody cross-checked, an assumption everyone treated as settled, or a gap in the evidentiary chain that only becomes obvious once opposing counsel points it out in front of a judge.
An AI system that waits entirely for the right question can still miss this category of risk.
Because nobody asked.
A different question: what don't we know?
The idea I've been designing around inverts the usual approach.
Instead of only answering what the evidence says, the system should also actively surface what the available evidence doesn't establish, and flag that gap as something requiring attention rather than treating silence as an answer.
Imagine that, for every material proposition in a case, the system maintains something like this:
Claim: The disputed communication was sent by the account holder.
Evidence currently available: Login record, email metadata, one witness statement.
Evidence potentially missing: Authentication logs, device history, IP records, provider access logs covering the relevant period.
Why the gap matters: The available material may establish that the account was used, but not necessarily that a particular person or device sent the communication. Attribution therefore remains contestable.
Recommended next step: Determine whether provider or device-access records exist for the relevant period and, if appropriate, seek them before they become unavailable.
This is a small example, but the pattern can generalize across an entire case.
Every witness statement. Every contested date. Every material allegation. Every proposition resting on only partial documentary support.
The output isn't simply another narrative summary of the case.
It's a structured map of where the case stands, where the evidence is strong, and where it does not yet stand at all.
But how does a system know something is missing?
This is the difficult part.
A system cannot call something "missing" unless it has some basis for believing that the evidence should exist, might ordinarily exist, or would be relevant to establishing the proposition in question.
That requires more than semantic search.
For each material proposition, the system would need to reason about the kinds of evidence that could support or undermine it: documentary records, communications, system logs, witness testimony, financial trails, timelines, approvals, provenance, authentication, or other evidence depending on the nature of the case.
In other words, the task is not merely:
What documents do we have?
It is also:
What would we ordinarily expect to examine before treating this proposition as established?
That distinction matters.
The system should not invent evidence that ought to exist. Nor should it present an absent record as proof of anything. It should identify an unresolved evidentiary question, explain why that question follows from the material already available, and let the lawyer determine whether the gap is real, relevant, obtainable, or immaterial.
This is less about magically discovering every "unknown unknown" in a case.
It's about systematically turning some unknown unknowns into known unknowns while there is still time to investigate them.
Why gaps matter more than answers
Opposing counsel's job, in an adversarial system, is in significant part to find these weaknesses precisely: the places where your case rests on an inference, an assumption, an incomplete chain of evidence, or a witness whose account doesn't quite align with the documents.
The earlier your own side identifies those weaknesses, the more options you have.
You may obtain the missing evidence.
You may discover that the evidence doesn't exist.
You may reconsider part of the theory of the case.
Or you may decide that the gap cannot be closed and prepare a considered response to it before somebody else raises it.
A system that only tells you what you already have can make preparation faster.
A system that also tells you what you may still need could make preparation different.
It changes the question from:
"Have we read everything?"
to:
"What would we still need to know before we were comfortable defending this proposition?"
Then attack your own case
There is a related capability that I think matters just as much, but it is slightly different.
Finding gaps is one task.
Actively exploiting them is another.
Once the system has mapped the claims, evidence, contradictions and unresolved questions in a case, it should be capable of switching sides.
If instructed to act as opposing counsel, how would it attack the case?
Which witness accounts conflict?
Which propositions rely disproportionately on one source?
Which dates don't reconcile?
Which documents support an inference without actually proving it?
Where is causation assumed?
Where is attribution uncertain?
What would a hostile cross-examination focus on?
What alternative interpretation of the same evidence could reasonably be advanced?
The purpose wouldn't be to predict exactly what opposing counsel will say. It would be to subject your own case to structured adversarial pressure before somebody else does.
These are therefore two related but distinct functions:
Gap detection: What haven't we established yet?
Adversarial testing: Given what we have established, how could someone attack it?
The goal of both is the same: surface risk while there is still time to do something about it.
What this isn't
This kind of system should not be presented as a replacement for legal judgment.
Quite the opposite.
Every gap it identifies, every contradiction it flags, and every vulnerability it suggests should be traceable to the material from which the conclusion arose.
A lawyer should be able to move from an AI-generated observation directly to the relevant document, page and passage and see exactly why the system raised it.
If the system says two accounts contradict each other, show both.
If it says a proposition is supported only indirectly, show the chain of evidence.
If it suggests that a particular category of evidence might be missing, explain why that evidence would matter.
And where the system is uncertain, it should say so plainly.
There is an important difference between:
"The evidence does not establish this."
and
"Based on the material currently available to the system, I cannot establish this."
Legal AI needs to understand that distinction.
Evidence-grounded and verifiable versus persuasive but unverifiable is, in my view, one of the lines separating an AI tool that genuinely reduces risk from one that quietly introduces new risk into a case.
Where this goes next
This is currently a design, not a finished product, and I think that's the honest way to describe it.
Before building further, I want to test the underlying problem against how litigators, in-house counsel and law firms actually work today.
How do legal teams currently identify gaps in large case files?
At what stage do they usually discover that something important is missing?
How much of this happens systematically, and how much depends on the instincts and experience of individual lawyers?
What tools already help?
Where do those tools fall short?
And, most importantly, would a system that continuously maps evidentiary gaps and stress-tests the case actually change how lawyers prepare, or would it simply become another dashboard nobody has time to look at?
If you litigate, manage a firm's caseload, work in-house, or have been on the other side of one of these late-discovered gaps as a litigant, I'd like to hear about it.
What's the moment in your own case preparation where you most wished you'd known what you didn't know?
Those conversations, rather than my own assumptions about the problem, should decide whether this is worth building and what it should actually do first.
Reach out at info@usscpartners.com. I'm setting up a handful of conversations with practicing lawyers over the next few weeks.