A checkpoint is where a person confirms an AI output and the work moves on. What a good one holds, where they belong, and why it’s a workflow feature.
It’s 8:40 and the docketing manager’s mail tool has already read the overnight PTO mail. Each piece on her screen carries a suggestion: this matter, this document type, this response date. Read the suggestion. Glance at the first page of the action beside it. Confirm, or fix it and confirm.
Down the hall an attorney opens a drafted response to a non-final. She reads it the way she’d read an associate’s draft, because her name goes on it. She changes one argument and signs off. The paralegal who’ll prep it for filing has it a minute later.
Neither moment is an AI feature. They’re checkpoints, and they’re the piece most legal AI conversations skip.
What is a workflow checkpoint?
A workflow checkpoint is the moment a named person looks at what an AI produced, decides whether it’s right, and by deciding, moves the work to its next step. Not a review policy. A specific stop in the workflow, with a specific owner, where the output either becomes work in motion or goes back.
Most checkpoints in a practice today are an email that says “please review attached.” Confirm is a reply. Reject is a longer reply. The record is somebody’s mailbox.
A checkpoint that’s built rather than improvised has six parts.
- Who confirms. A role, and a name when it fires. Not “the team.” - What’s being checked. One thing, named. This piece of mail’s classification, this suggested date, this drafted response. - What the reviewer sees. The output beside its evidence. The proposed date next to the face of the action. - What confirm does. Where the work lands, and who has it next. - What reject does. Where it goes back to, and who’s told. - The record. That it happened, who did it, when, and what they changed.
Take any one away and you don’t have a checkpoint. You have a person clicking a button and hoping.
Where do checkpoints belong in a prosecution workflow?
Anywhere an output is about to become something the practice treats as true. Four show up in nearly every patent group.
The incoming office action. The tool proposes a matter, a document type, and the response date. The docketer confirms, and the action is on the matter, the date is on the docket, and whoever preps the response has it in their queue. She rejects, and it comes back to her as unplaced. Nothing has touched the docket.
The drafted response. The attorney whose name goes on the filing reads it against what the firm argued in the parent. Confirm makes it the version the paralegal preps for filing. Reject sends it back with her notes before the paralegal preps a version that’s about to change.
The suggested prep date. A soft date is the docketer’s arithmetic, worked backward from the hard date. A tool can suggest one, but it stays a suggestion until the person who owns the docket accepts it or moves it, and the change is on the record. The docket catches dates, but it shouldn’t take one from a tool without someone saying yes.
The client status summary. Drafted from the matter record, read by the paralegal who knows that client or the attorney who owns the relationship. Confirm sends it in the format the client expects and marks the matter as reported. Reject means nothing leaves the building.
Why is a checkpoint a workflow feature and not an AI feature?
Because it was there before the AI was.
When an associate drafted the response, the partner read it before it went out. The checkpoint is old. What’s new is what arrives at it: more output, faster, and looking like the final. Finished-looking work is the kind that slips past a stop. We made that case in Count the Handoffs, and it’s why a checkpoint now has to be built instead of remembered.
In a restaurant kitchen, the cook makes the plate. The chef at the pass looks at it, sends it or sends it back, and the runner takes it to the table. The pass isn’t a feature of the oven, and a better oven doesn’t give you one. The tool doesn’t know who your attorney of record is or what this client expects in a status report. The checkpoint does, because it’s part of how your work moves, not how the draft got written.
Accuracy is the wrong argument against one. The checkpoint isn’t there because the AI is bad. It’s there because the work has an owner, and the owner is a person.
What about AI that already knows your docket?
Some tools now read your firm’s own matter data, so the AI knows the family, the dates, and the history before anyone types a question. That’s genuinely useful. The docketer confirms more and fixes less.
But reading the docket is an input. Knowing the docket isn’t moving the docket. An AI with perfect knowledge of every matter still hands a person an output, and the checkpoint is where that output either becomes work in motion or sits. And the better-informed the output, the more the checkpoint matters. It will look right more often, and the one time it isn’t will look right too.
The “AI-native” label describes how a vendor built their product. “Knows your docket” describes what it can read. Neither tells you who confirms, what they see, or where the work goes next. Those are the checkpoint’s questions, whatever tool you buy.
How do you tell a real checkpoint from a rubber stamp?
Ask three things about any review step, in a tool you’re evaluating or one you already run.
What did the reviewer see? A suggestion with an approve button and nothing beside it means the reviewer is guessing with a nicer interface.
What happened the moment they confirmed? If a person still carried the result to the matter, the docket, or the client by hand, the checkpoint didn’t move the work. It added a click in front of the carrying.
Can you find that confirmation next month? The partner taking the client’s call and the associate picking up the case midstream both need to see who said yes and what changed. If the answer lives in a mailbox, it doesn’t exist.
The sharper use is on your own workflow, today. Walk one office action from the mail to the client and mark every place a person confirms something. Then ask which of those stops has all six parts. The people and the habits are usually there. The record usually isn’t.
A stop like that, with an owner, evidence, and a record, is what PracticeLink is built to hold. But the idea doesn’t need a product. It needs a decision about where the work stops and who says go.
The next round of tools will produce more and look more finished doing it. The practices comfortable running them won’t be the ones with the best model. They’ll be the ones that can point to every stop between the output and the client and name the person standing at it.
Part of our series on modernizing IP operations.