Every practice has the stack.
Mail comes in. Somebody scans it, or the scanner emails it, or a client forwards something, or an e-service notice lands with an attachment. It piles up in a folder full of names like Scan_2026-07-24_113402.pdf, and it sits there, sometimes for a day, sometimes longer, because working through it is a chore and chores never win the fight for the top of the desk.
That stack is one of the most dangerous things in a law office. No single page in it is usually a crisis. The problem is that deadlines come into a practice through it, and an unprocessed stack is a pile of deadlines nobody has started counting. A two-day-old inbox is a real malpractice risk.
It’s also exactly the kind of work a machine ought to be doing: repetitive, high-volume, full of patterns, and consequential in narrow, predictable ways. Here’s the pipeline we run.
Six steps, always in order
Every document goes through the same six steps in the same order. Each step builds what the next one needs. Run them out of order and you get confident nonsense.
1. Make it readable
A scan is a picture of a document, and nothing downstream can do anything with a picture. So step one is optical character recognition, run automatically on anything that shows up without a text layer.
I don’t ask a human about this one. There’s no judgment in it. A PDF has extractable text or it doesn’t, and if it doesn’t, it gets OCR’d. A prompt asking permission to make a document readable only exists to get clicked through.
Two practical tips. Run OCR at intake, not on demand, or you’ll be re-running it every time somebody opens the file. And keep the original next to the OCR’d copy. OCR loses things, and every so often what it loses matters. If you might ever need to authenticate the document, the original scan is the real thing.
2. Figure out whose file it is
Which matter does this belong to?
This is the first real judgment call, and everything after it depends on getting it right. A document filed to the wrong matter is worse than one not filed at all. It’s missing where you’d look for it and confusing where it landed.
The good signals, best first: a court file number in the caption; a matter or file number the firm assigned; the caption matched against open matters; the sender matched against known opposing counsel.
The bad signal, the one that’ll tempt you, is the client’s surname. I’ve written about this before and I’ll keep repeating it because it keeps happening: surname matching gives you confident, wrong answers. Documents are crawling with names that aren’t your client’s. Judges, opposing parties, witnesses, court reporters, process servers. Match on surnames long enough and you’ll hang a document on a matter because it found the judge’s name.
So the rule is propose it, show the evidence, and let a human confirm. The output isn’t “this is the Whitfield file.” It’s “this appears to be 10024-Whitfield, matched on court file number 27-CV-26-XXXX appearing in the caption on page 1.” A match that shows its evidence takes two seconds to check. A bare assertion can’t be checked at all.
When nothing matches with confidence, the answer is unmatched, and that’s a perfectly good answer. It goes into a short queue for a person. It doesn’t get a guess.
3. Read it against the file
This is the step that turns a filing system into something worth having, and it’s the one most tools skip.
The question isn’t “what is this document?” Anybody can see it’s an answer, an order, or a discovery response. The question is what does this document mean for this case, given everything already in the file?
You can’t answer that without reading the matter file first. An order granting a motion in part means one thing or another depending on what was pending. A discovery response matters because of what it leaves out compared to the requests. A letter from opposing counsel matters or doesn’t depending on what the last three said.
Here’s where an AI assistant earns its keep, and it’s why the pipeline loads the matter’s existing documents before it looks at the new one. Hand an analyst one document and ask “is this important” and you’ve asked a question nobody can answer. Hand them where the whole case stands and then the new document, and now they can.
What comes out is a few sentences: what it is, what changed, and whether the case looks any different now.
4. Pull every date
Every date that could possibly be a deadline, a trigger, or an event comes out: hearing dates, response deadlines, service dates, discovery cutoffs, do-this-by dates, and above all the service date, because that’s what starts most clocks.
Two hard rules.
Pulling dates isn’t counting deadlines. This step grabs the dates in the document and flags which ones are triggers. It doesn’t calculate what’s due. That’s a separate job with its own rules, starting with pulling the governing rule text from the primary source before anybody does any arithmetic. Mash “the document says served July 24” together with “your response is therefore due August 26” and you’ve got a wrong deadline on the calendar with an official-looking pedigree.
Nothing goes on the calendar until a human says so. That’s the second sign-off in the pipeline, and it doesn’t bend. A calendar entry is a promise about when the work happens. A wrong one is worse than none. Anxiety eventually turns up a missing deadline. Nothing ever turns up a wrong one.
5. File it
Into the matter’s folder, into the right subfolder, under a name that’ll still make sense three years from now.
Filing runs on its own once the matter’s confirmed, because the judgment call is already made. The naming convention matters more than people think. 2026-07-24 Order Granting in Part Motion to Compel.pdf sorts by date, reads at a glance, and survives getting emailed to somebody. Scan_2026-07-24_113402.pdf does none of that.
One more rule: the document goes where documents live, not into the knowledge layer. If you keep a wiki or an index, it gets a page about the document that points to it. It doesn’t get a second copy. Two copies means two versions, and sooner or later somebody files the wrong one with a court.
6. Propose the follow-ups
Last question: what does somebody have to do now?
Draft a response. Call the client. Produce the withheld documents. Notice the deposition before that discovery cutoff you just calendared. These come out as proposed tasks on the matter, with the document that triggered them attached.
Proposed, again. Not created. The pipeline’s job is making sure nothing slips by. What the practice does about it isn’t the pipeline’s call.
Where the humans go
Six steps, exactly two sign-offs. That ratio is the whole design, and you can ruin the pipeline by missing it in either direction.
| Step | Who decides |
|---|---|
| 1. OCR | Automatic |
| 2. Match to matter | Human confirms |
| 3. Significance | Automatic, presented for reading |
| 4. Dates extracted | Automatic |
| → Deadlines calendared | Human confirms |
| 5. File to folder | Automatic (after step 2 confirmed) |
| 6. Follow-ups | Proposed, human accepts |
The rule: sign off on the things that are hard to undo and serious when they’re wrong. A misfiled document is annoying, and you can fix it. A missed deadline you can’t. A document hung on the wrong matter poisons everything after it, which is why matching gets a sign-off even though filing doesn’t.
Every sign-off costs something, and it isn’t clicks. It’s attention. Each approval you ask for spends a little of the reviewer’s limited patience for reading carefully. Ask for twelve and they’ll start clicking through all twelve, including the two that counted. A pipeline that asks about everything gets approved without being read. That’s worse than one that asks about nothing, because it leaves a record that suggests somebody checked.
Batch it, don’t stream it
Run the whole folder as one batch and put the results in a single table.
Your instinct will be to handle each document as it comes in, one conversation apiece. Don’t. It’s the same reason six terminal windows lose to one board: you’ve turned one sitting into fifteen context switches. Fifteen documents one at a time means getting your bearings fifteen times, on a different matter, a different set of facts, a different question.
Run as a batch, those fifteen documents give you one table: what each one is, which matter it matched and why, what it means, what dates it carries, what’s proposed. You read it once, top to bottom, approving and fixing as you go. It takes a fraction of the time. Better yet, you’re in one frame of mind the whole way through, and that’s when people actually catch mistakes.
What this isn’t
It isn’t a substitute for reading. The significance summary tells you which of the fifteen you need to read carefully today. It doesn’t read them for you, and anything with legal consequences gets read by a lawyer.
It isn’t the system of record. The matter folder is. The calendar is. The practice management system is. The pipeline moves things into them. It isn’t one of them.
And it isn’t a way to make the stack somebody else’s problem. It’s a way to make sure that by the end of the day every deadline hiding in that stack has been counted. That’s the whole job.
General commentary on practice management. Not legal advice. All matters, file numbers, and documents referenced above are invented for illustration; no client information appears in this article.