// specific build playbooksby 6 min read

AI Conflict Check for Law Firms in 90 Lines

Conflict checking is the highest-stakes routine work in a law firm. An AI-assisted pattern that catches name variations and flags the corporate links a substring search misses.

Conflict checks are the most-disliked work in a law firm. They're slow, error-prone, and consequential. Miss one and you lose a client or violate ethics rules.

The pattern below runs a conflict check in seconds rather than minutes, and catches the name variations and corporate adjacencies that a substring match misses.

What most firms have before

The conflict tool inside a practice management system is usually a substring match. Type "Acme Corporation," it returns matters involving "Acme Corporation."

It misses:

  • "Acme Corp" vs "Acme Corporation"
  • "Acme Holdings" as a parent of Acme Corp
  • "John Smith" vs "John A. Smith" vs "Jonathan Smith"
  • A former employee of opposing counsel now working at the prospect
  • Adjacent matter types (we represent Acme in IP; new prospect is suing Acme's subsidiary in employment)

Each miss is potential malpractice, which is why risk partners end up doing the cross-references by hand.

The build

Step 1: Build a clean prospect record. When a new matter comes in, capture:

  • Client name + any aliases
  • Parent/subsidiary relationships if known
  • Key individuals (officers, attorneys, witnesses)
  • Adverse parties
  • Matter type / practice area
  • Relevant time period

Step 2: Pull all candidates from the CMS. Substring match on the prospect's name, parties, key individuals. This is what the old system did. It can return dozens or hundreds of candidates.

Step 3: Claude scores each candidate. For each candidate matter from the CMS, send to Claude:

Score this potential conflict.

Prospect: {prospect_data}
Existing matter: {existing_matter_summary}
Relationship between names: {string_similarity, parent_subsidiary_check}

Return:
- conflict_likelihood: 0-10
- conflict_type: "direct" | "former_client" | "positional" | "adjacent" | "personnel" | "none"
- reasoning: one sentence
- recommended_action: "decline" | "consent_required" | "screen" | "no_conflict"

Score 6+ requires human review. Score 9+ should be assumed conflict pending clearance.

Step 4: Aggregate and present. The system returns a ranked list. The risk partner reviews the top 10 (or all 9+ scores). The long candidate list has been narrowed to a handful with clear reasoning.

Step 5: Name variation pre-check. Before scoring, expand prospect names using a name-normalization step:

  • "Corporation" / "Corp" / "Inc" / "LLC" / "Ltd" all map to a normalized form
  • Common first-name nicknames are expanded (Bob → Robert, Bill → William, etc.)
  • Last-name suffixes (Jr, Sr, III) are stripped for matching but flagged separately

The pre-check expands the candidate pool. Claude then narrows it.

The 90-line claim

The whole pattern (excluding the CMS query layer which is firm-specific) is about 90 lines of code:

  • ~20 lines for name normalization
  • ~15 lines for parent/subsidiary lookup (a company-data provider such as Clearbit as a hint, then human verification)
  • ~30 lines for the Claude scoring loop
  • ~25 lines for aggregation and presentation

The CMS query layer is whatever your CMS exposes. Aderant has an API. Other firms have other paths. Plan on a few days of integration work there.

How to measure it

Track two things from the first day: the time each check takes from intake to clearance, and the conflicts the system surfaced that the old substring search would have missed. Keep the second list with the documented clearance decisions. It is the evidence that the tool is worth keeping.

What tends to break

Over-flagging. A cautious first prompt sends too much to review, and the partners drown in it. Tighten the scoring so a high score means specific evidence of a likely conflict, not "names appear similar."

Parent/subsidiary data is hard. Commercial company data is useful but not authoritative. SEC filings are authoritative but harder to parse. A workable hybrid flags potential parent/subsidiary relationships from the commercial data and asks a paralegal to verify before clearance is final.

The system needs the human in the loop. Claude doesn't make conflict decisions. It surfaces likely conflicts with reasoning. A licensed attorney (the risk partner) makes the call.

What this isn't

This is not a replacement for the firm's conflict-clearance process. It's a triage tool. The clearance decision is still a human, licensed attorney's decision.

It's also not a substitute for thorough new-matter intake. Garbage in, garbage out. The system depends on the prospect record being clean. If the partner doing intake skips parts, the system misses things.

What to build first

If you're at a law firm with this problem:

One, the name normalization layer. This alone improves the existing CMS search materially. No AI required.

Two, the Claude scoring of candidates. Layer this on top of the existing CMS search. You don't need to replace the CMS — you augment it.

Three, the parent/subsidiary check. Last because it requires data sourcing decisions.

Scope the build around your CMS API, which is the part that varies most from firm to firm, and judge the payback against the risk partner's time before and after.

law firmconflict checklegal techailong-tail
// go deeper

Worked steps, FAQs and resources on this topic.

read the guide
// the_list

Get the next one.

Field notes from real deployments, written the way this one was. No schedule promised and nothing sold to you. Unsubscribe whenever.

// keep reading

Related posts

// ready to ship?

Let's build yours.

Reading is the easy part. We do the work. Tell us what's broken and we'll tell you straight up whether we can help.