1873: The Citator 

Frank Shepard was a salesman in Illinois. He noticed that lawyers had a terrible problem: you could find a case, but you had no reliable way to know whether it was still a good law. Cases were overruled, distinguished, and quietly gutted, and the only way to find out was to read everything that came after, or to find out the hard way, in front of a judge. 

His solution was almost stupidly simple. He printed small adhesive slips listing every subsequent case that had cited a given decision, and lawyers pasted them into the margins of their own reporters. Around the same time, John West was building the National Reporter System and the key number taxonomy that would organize the entire body of American case law into a navigable structure. 

Neither man wrote a single word of law. They just made the law findable. That was enough to define how lawyers worked for the next hundred years. 

1973: Full-Text Search 

In 1973, Mead Data Central launched LEXIS, and something that had been true for a century stopped being true. You no longer needed to know the taxonomy to find the case. You could just type the words. 

The digest, that monument of human classification, became optional. Westlaw followed in 1975, and within a generation the first-year associate ritual of walking into a physical library was gone. What made this revolutionary wasn't speed. It was that the index no longer had to be built by hand, in advance, by someone guessing what you'd want to look for. 

2006: The Document Explosion 

Then the record got bigger than the reader. 

In December 2006, the Federal Rules of Civil Procedure were amended to formally recognize electronically stored information. Zubulake had already put preservation on every general counsel's desk. In 2012, a magistrate judge in the Southern District of New York blessed predictive coding, and technology-assisted review entered the vocabulary of ordinary litigation. 

Here's the part that doesn't get said enough: this was the first inflection point that made the practice of law harder. Shepard made the law findable. LEXIS made it searchable. E-discovery made it enormous. A trucking case that would have produced four bankers boxes in 1985 now produces telematics data, dashcam footage, driver qualification files, ELD logs, maintenance records, and 40,000 pages of medical billing. 

We got a search box pointed at an ocean and called it progress. 

What's next? 

AI, obviously. It arrived in legal the way it arrived everywhere else, as a chat window. 

And it's genuinely useful. Summarize this deposition. Draft this motion. Chat with this PDF. We use these tools. They're good. But if you're a partner carrying sixty active matters, a chat window is not an answer. It's an assignment. It assumes you already know which document to ask about, which is precisely the thing you don't know at 9 p.m. on the night before a mediation. 

Worse, almost every serious legal AI product has been built for the same customer: the transactional practice. Contract review. Diligence. Deal work. That's a real market with real money, and it is nothing like litigation. 

Litigation has its own physics. Your record wasn't authored by your client, it was assembled out of what an adversary decided to produce, when they decided to produce it. Your deadlines come from a court, not from a calendar you control. You carry dozens of matters simultaneously across venues with different standards. The facts aren't agreed, they're contested, and the entire job is finding the point where the other side's version stops holding together. And your downside isn't a bad indemnity clause. It's a verdict. 

A tool built to read a credit agreement does not know any of that. It can't, because nobody built it to. 

We think the next layer needs three things. 

1. The matter is the unit, not the document 

Ask a litigator what a case is and they will not describe a folder. They will describe a structure: who the parties are, what the alleged mechanism of injury is, which providers treated the plaintiff and in what sequence, where the treatment gaps are, which experts have been designated, what the prior claims history looks like, what the exposure picture is, and where the story falls apart. 

That structure is the case. Documents are just where it happens to be written down. 

So we don't index documents. We build a matter-level intelligence graph, entities, events, timelines, and relationships extracted across the entire file and connected to each other. When a billing record contradicts a treatment note, that's not two search results. That's one finding. Case Intelligence means the system understands the shape of the matter, not just the text inside it. 

2. Built for litigation, not for deals 

Generic extraction produces generic output. A litigation-specific workflow knows that a fourteen-month treatment gap matters, that a lien changes the damages posture, that an IME and a treating opinion are different animals, that a Rule 26 designation carries a deadline attached to it, and that "prior similar incidents" is the phrase that decides product liability cases. 

We built our workflows for each practice, med mal, mass tort, toxic tort, trucking, product liability, nursing home, catastrophic injury, business litigation, construction, real estate, employment and more, because those are different practices, not different filters on the same practice.  

Each workflow mirrors how experienced litigators build and evaluate a case, with practice-specific legal judgment built into every stage. Turbo continuously checks its own work for missing facts, overlooked issues, and inconsistencies, keeping the analysis focused and reliable from start to finish. 

3. Answers that survive cross-examination 

There is a category of software where a plausible-sounding wrong answer is a minor annoyance. Litigation is not in that category. 

Every output has to trace to the record, page, Bates, source, exhibit. Not because it's a nice feature, but because an attorney's license is the thing standing behind it. If a finding can't be verified in ten seconds, it isn't usable, and an unusable finding at scale is worse than no finding at all. 

That's also why we treat this as workflow engineering rather than prompt engineering. Enterprise document management, permissioning, ethical walls, audit trails, and reliability that holds at 30,000 pages. The unglamorous half is the half that determines whether anyone actually adopts it. 

The part nobody says out loud 

What actually constrains a litigation practice isn't how fast you can read. It's how much of the record you can genuinely know before you have to make a decision about it. 

That shows up in five places.  

• Rate, can you justify your pricing, or prove your valuation, with work product that holds up.  

• Utilization, how much of your capacity goes to substantive work instead of reading. 

• Leverage, can an associate produce partner-grade analysis.  

• Expenses, how much walks out the door to contract reviewers and vendors.  

• Speed, does faster case assessment produce better resolutions and more of the work you want. 

Getting through the file faster is table stakes. Knowing what's in it before the other side does is the business. 

The crossroads 

Shepard made the law findable. Mead made it searchable. E-discovery made it infinite. 

The question in front of the trial bar right now is who builds the layer that makes it knowable, and whether that layer gets built by people who understand the difference between a deal room and a courtroom, or by people who think litigation is contract review with more paper. 

We know which one we're betting on. 

We're a team of engineers, designers, and litigators, building Case Intelligence for the firms who try cases. If that's your work, we'd like to hear how you'd do it differently. 

-Jay and Ozgur