top of page

What We Mean When We Talk About Our Expertise

By Kevin Miller

Plenty of companies are sniffing around the analyze-before-you-sign part of the artificial-intelligence-and-contracts space. And DocuSign, perhaps the most successful legaltech company, recently announced it was joining their ranks.

We keep an eye on our competition, but we’re not concerned. We’re confident that if we follow our plan, we’ll do well. And the attention that DocuSign brings to this business can only help us.

Beyond that, it’s silly to think too much about the competition. Innumerable factors—some that you might control, some that you might not—go into determining who prevails. And the annals of business are full of companies that succeed in one business and fail at another. That includes companies with plenty of money to throw at a new undertaking. So we’ll continue minding our business.

But I permit myself to point out one factor that continues to distinguish LegalSifter: our commitment to expertise. That sounds like the usual business blather, like promises that one is committed to “excellence.” But in our case, it’s a key part of our business plan.

To help most people reviewing a draft contract, you can’t just have technology look for patterns, as if you were dealing with some natural phenomenon, like the weather. Instead, you have to decide what issues you’re looking for and the different ways they’re expressed. That requires deal experience combined with a knack for language. And once the software spots an issue, or determines that it’s missing, you have to suggest to the user the significance of that issue.

That sounds like it should be easy enough, but it’s not. Business contracts have long been drafted by copy-and-pasting from precedent contracts of questionable quality and relevance. One result is that it’s routine for drafters to have only an uncertain grasp of the implications of what they’re copying. Another result is that contract language is mostly chaotic. So instructing the software what to look for is a challenge, and offering meaningful help text to users is also a challenge.

Who should we trust with these tasks? LegalSifter has elected to give this task to experts, not to an anonymous team of lawyers.

In particular, our chief content officer is Ken Adams. Ken single-handedly invented and made his own a new discipline—the rigorous study of the building blocks of contract language. No one comes close to matching the depth, imagination, and sheer volume of Ken’s 25 years of scholarship. That explains why in a recent opinion, the Delaware Chancery Court—the most influential business-law court in the United States—cited Ken’s work several times, acknowledging his stature and the quality of his work. (For more about that, see this post on Ken’s blog.)

Whereas the legal profession tends to rely on misbegotten conventional wisdom to explain away the dysfunction in contracts, we have Ken’s expertise to cut through the fog. And with Ken’s help, we’re continuing to build a roster of subject-matter experts to guide our analysis of different kinds of contracts.

But don’t assume that Ken’s a dainty professorial type. He’s scarily committed, and he’s engaged in a prolonged slog, one issue at a time. See for example his recent post on a phrase used in information-security provisions, the principle of least privilege (here).

Having Ken on our team wasn’t an accident. I sought him out and convinced him to roll up his sleeves and combine his expertise with our technology. He needed little convincing because he had long intended to use technology to expand the reach of his approach to contract language. And LegalSifter was the first to make Ken such an offer.

I’m not shy about talking about Ken and our commitment to expertise. If you don’t showcase your expertise, it’s likely you don’t have much.

#legaltech #legalsifter

Recent Posts

See All

Recently I noticed this article on Artificial Lawyer. The title is Generative Legal AI + “The Last Human Mile”, and it’s about limits to applying AI to legal work. It says this: The last mile problem

bottom of page