From the Scanner to the Calendar: A Document Intake Pipeline

Every practice has a version of 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 with names like Scan_2026-07-24_113402.pdf, and it sits there — sometimes for a day, sometimes longer — because processing it is a chore that is never the most urgent thing on the desk.

That stack is one of the most dangerous objects in a law office. Not because any single document in it is a crisis, but because deadlines enter a practice through it, and an unprocessed stack is a set of deadlines nobody has started counting yet. The malpractice risk of a two-day-old inbox is not theoretical.

It is also, structurally, exactly the kind of work that should be automated: repetitive, high-volume, pattern-heavy, and consequential in a narrow and predictable way. This is the pipeline we run.

The six steps

Every document goes through the same sequence, in the same order. The order is not arbitrary — each step produces the input the next one needs, and doing them out of order produces confident nonsense.

1. Make it readable

A scan is a picture of a document. Nothing downstream can work with a picture. So the first step is optical character recognition, applied automatically to anything that arrives without a text layer.

This step is fully automatic and I would not ask a human about it. There is no judgment involved: a PDF either has extractable text or it does not, and if it does not, it gets OCR’d. Asking permission to make a document readable is a prompt that exists only to be clicked through.

Two practical notes. Run OCR at the intake stage rather than on demand, because otherwise you will re-run it every time somebody opens the file. And keep the original alongside the OCR’d version — OCR is lossy in ways that occasionally matter, and for a document you may need to authenticate, the original scan is the artifact.

2. Identify the matter

Which file does this belong to?

This is the first genuine judgment, and it is the one everything downstream depends on. A document filed to the wrong matter is worse than a document not filed at all: it is invisible where it should be and confusing where it is.

The reliable signals, in descending order: a court file number appearing in the caption; a matter or file number the firm itself assigned; the case caption matched against open matters; the sender matched against known opposing counsel.

The unreliable signal, and the one that will tempt you, is the client’s surname. I have written about this failure before and it is worth repeating because it recurs: matching on surnames produces confident, wrong answers. Documents are full of surnames that are not your client’s — judges, opposing parties, witnesses, court reporters, process servers. A system that matches on surnames will eventually attach a document to a matter because it found the judge’s name.

So the rule is: propose, with the evidence, and let a human confirm. The output is not “this is the Whitfield file.” It is “this appears to be 10024-Whitfield, matched on court file number 27-CV-26-XXXX appearing in the caption on page 1.” A match with its evidence attached can be checked in two seconds. A bare assertion cannot be checked at all.

Where nothing matches confidently, the answer is unmatched, and unmatched is a fine answer. It goes in a short queue for a human. It does not get a guess.

3. Assess significance — against the file, not in isolation

This is the step that separates a filing system from something actually useful, and it is the one most tools skip.

The question is not “what is this document?” Anyone can see that it is an answer, or an order, or a discovery response. The question is: what does this document mean for this case, given everything already in it?

Answering that requires reading the matter file first — not just the new document. An order granting a motion in part means something different depending on what was pending. A discovery response is significant because of what it omits relative to the requests. A letter from opposing counsel matters or does not matter depending on what was said in the last three.

This is where an AI assistant earns its keep, and it is why the pipeline pulls the matter’s existing documents into context before it evaluates the new one. Handing an analyst a single document and asking “is this important” is a question that cannot be answered. Handing them the whole posture and then the new document is a question that can.

The output is a few sentences: what this is, what changed, and whether anything is now different about the case.

4. Extract every date

Every date that could conceivably be a deadline, a trigger, or an event comes out: hearing dates, response deadlines, service dates, discovery cutoffs, dates by which something must be done, and — critically — the service date, because that is what starts most clocks.

Two hard rules here.

Extraction is not computation. This step pulls the dates that appear in the document and identifies which are triggers. It does not calculate the resulting deadlines. That is a separate operation with its own requirements, chiefly that the governing rule text be retrieved from the primary source before any arithmetic happens. Conflating “the document says served July 24” with “your response is therefore due August 26” is how a wrong deadline gets onto a calendar with an authoritative-looking provenance.

Nothing goes on the calendar without a human saying so. This is the second confirmation point in the pipeline, and it is not negotiable. A calendar entry is a promise about when work will happen. A wrong one is worse than none, because a missing deadline gets discovered by anxiety and a wrong one does not get discovered at all.

5. File it

Into the matter’s folder, into the correct subfolder, with a name that will still make sense in three years.

Filing is automatic once the matter is confirmed, because by that point the judgment has already been made. The naming convention matters more than people expect — 2026-07-24 Order Granting in Part Motion to Compel.pdf sorts chronologically, reads at a glance, and survives being emailed to somebody. Scan_2026-07-24_113402.pdf does none of those things.

One rule worth stating: the document goes where documents live, not into the knowledge layer. If you maintain a wiki or index, it gets a page about the document that points at it. It does not get a second copy. Two copies means two versions, and eventually the wrong one gets filed with a court.

6. Propose follow-ups

Finally: what does somebody now have to do?

Draft a response. Call the client. Produce the withheld documents. Notice the deposition before the discovery cutoff you just calendared. These come out as proposed tasks against the matter, with the document that generated them attached.

Proposed, again — not created. The pipeline’s job is to make sure nothing goes unnoticed, not to decide what the practice does about it.

Where the humans go

Six steps, exactly two confirmation points. That ratio is the whole design, and getting it wrong in either direction ruins the pipeline.

The principle: confirm the things that are hard to reverse and consequential when wrong. A misfiled document is annoying and fixable. A missed deadline is not. A document attributed to the wrong matter poisons everything downstream, which is why it is gated even though the filing itself is not.

Confirmation is expensive — not in clicks, in attention. Every approval you ask for spends a little of the user’s finite willingness to read carefully. Ask for twelve and they will start clicking through all twelve, including the two that mattered. A pipeline that asks about everything is a pipeline that gets approved without being read, which is worse than one that asks about nothing, because it produces a record suggesting somebody checked.

Batch, don’t stream

One structural choice worth arguing for: run this as a batch over the whole folder, and present a single table.

The instinct is to process each document as it arrives, one conversation per document. That is worse, for the same reason six terminal windows is worse than a board: it turns one decision session into fifteen context switches. Fifteen documents processed individually means fifteen times re-orienting to a different matter, a different posture, a different question.

Processed as a batch, the same fifteen documents produce one table: what each one is, which matter it matched and on what evidence, what it means, what dates it carries, what is proposed. You read it once, top to bottom, approving and correcting as you go. It takes a fraction of the time and — more importantly — you are in a single frame of mind for all of it, which is when people actually catch errors.

What this is not

It is not a substitute for reading. The significance summary tells you which of the fifteen documents you need to read carefully today. It does not read them for you, and anything with legal consequence gets read by a lawyer.

It is not a system of record. The matter folder is. The calendar is. The practice management system is. The pipeline moves things into those systems; it is not one of them.

And it is not a way to make the stack somebody else’s problem. It is a way to make sure that by the end of the day, every deadline hiding in that stack has been counted — which is the actual goal, and the only one that matters.

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.