The lawyer approves; the AI proposes: how we design Meruit

There are two ways to build AI into legal software. One is to make it as automatic as possible: the system reads, decides and sends, and a person checks if they have time. The other is to make the AI do the first pass, show its working, and wait for a person to decide.

We chose the second, and we wrote it down as the first of our product principles: the lawyer approves; the AI proposes. This post explains why, and what it means in practice.

Why not fully automatic?

Partly because of the rules. Lawyers are responsible for the work that goes out under their name, and for supervising the people and tools that help them. ABA Formal Opinion 512, the ABA's 2024 opinion on generative AI, is built around that idea: AI doesn't change who is responsible.

But mostly because of what AI is like. Today's language models are very good at producing fluent, plausible text. They are also capable of producing fluent, plausible text that is wrong, and it doesn't look any different. A system that hides the AI's work behind a finished-looking result makes those mistakes harder to catch, not easier.

So we design for checking. That comes down to three habits.

1. Every AI fact shows where it came from

When Meruit suggests a chronology entry from a medical record, the entry carries the page number it came from and a short quoted line from that page. You can see, at a glance, what the AI is relying on.

We go one step further. Before showing a suggestion, Meruit checks that the quoted line really appears on that page of the document. Language models can misquote, or invent a quote that sounds right. Checking the quote against the actual page text catches that kind of error before anyone has to.

Our second principle covers the general case: every claim cites its source, and if there's no source, Meruit says so instead of guessing.

2. Nothing counts until a person says so

AI suggestions in Meruit are suggestions until someone acts on them:

• Chronology entries join the chronology only when someone on your team approves them. The medical specials total adds up approved entries only.
• Limitation dates suggested from the state table don't count as deadlines until a lawyer confirms them.
• Demand letters are locked only when a lawyer approves them, and the approval stamps the letter with their name and the time.

That last one matters most, because a demand letter leaves the office. Nothing goes to a client, a court or the other side without a named lawyer's approval.

3. Every approval is on the record

Approvals aren't just a button. Meruit records who approved what, and when, in an audit log that can't be edited from inside the application. If a question ever comes up about what was approved and by whom, the answer is there.

What this costs, and why it's worth it

Designing this way does mean more clicks than a fully automatic system. Someone has to review the chronology entries. A lawyer has to confirm the limitation date. We think that's the right trade.

Reviewing a suggestion that shows its source is much faster than building the same work from nothing. A paralegal approving a chronology entry with the page and quote in front of them is doing a quick check, not hunting through a PDF. And the time spent is the kind of time that protects the firm.

What we won't build

Following the same principles, there are things we've decided not to do:

• No client-facing assistant that gives legal advice. When we build intake and portal assistants, they'll collect facts and share lawyer-approved information only.
• No case or statute citations shown to you unless they've been checked against a licensed legal database. Research features will follow that rule when they arrive.
• No training of AI models on your firm's data.

You can read all eight principles on our About page, and how they show up in security on our Security & trust page.