E/05 · The teardown
The conflicts check teardown: redesigning intake's most avoided step
Conflicts checking is the one intake step almost every practice still runs on memory, a folder search and a hope. Here is what it looks like rebuilt on the six MATTER primitives, step by step, with nothing left to instinct.
By Raghav R Handa · Founder · August 2026 · 13 min
The workflow nobody redesigns
Everything else at intake gets rebuilt first. Conflicts checking rarely does.
Firms that systematise their intake almost always start with the visible parts: the engagement letter, the matter template, the fee quote. Conflicts checking sits quietly underneath all of it, and it is usually the last thing anyone touches, if anyone touches it at all.
That is the wrong order, for a specific reason. A matter that opens on an unresolved conflict is not a matter that runs efficiently later; it is a matter that has to be unwound, sometimes after months of work, sometimes after a client relationship has already formed. Every other inefficiency in a practice costs time. A missed conflict can cost the client, the fee, and the firm's standing with a regulator, all at once.
And yet, across every firm this studio has read the files of, conflicts checking is run the same way: someone with institutional memory searches a name across whatever system exists, a document management folder, an email archive, a spreadsheet nobody else opens, and decides, from recall, whether the name rings a bell. It is judgment applied to a task that should never have depended on judgment in the first place. Judgment belongs at the escalation point, on the ambiguous match. It has no business being the entire mechanism.
This teardown rebuilds that workflow on the six MATTER primitives, in the order the doctrine always insists on: name it, systematise it, automate it. Nothing here requires new software. It requires a different container, a written sequence, and one rule about who decides on an ambiguous name.
The diagnosis
What a conflicts check actually is, once you stop calling it a formality.
A conflicts check answers one structural question: has this firm, or anyone it currently represents, stood on the opposite side of any party now proposing to become a client, or any party materially connected to this matter? Stated that plainly, it is obviously a matching problem against a defined set of records. Run informally, it is instead a memory-retrieval problem against an undefined set of places a name might be hiding.
The gap between those two descriptions is the entire redesign. A matching problem against a defined set of records can be named, timed, assigned and eventually automated. A memory-retrieval problem against an undefined set of places cannot be any of those things, because there is no fixed thing to point a system at.
The redesign
The conflicts check, rebuilt on all six primitives.
Each primitive answers a specific structural gap in how conflicts checking is normally run. Together they turn a memory exercise into a repeatable, auditable step.
Matter - separate the party registry from the matter file
The single most common design error: treating every prior matter's party list as the searchable record, instead of maintaining one registry of every party the firm has ever represented, opposed, or advised adjacent to.
A matter file tells you who was involved in one engagement. It does not, by itself, tell you whether a name recurs across forty other engagements under a slightly different spelling, a maiden name, a trading name, or a subsidiary. The fix is structural, not procedural: build one party registry as its own container, separate from any individual matter, holding every party the firm has ever touched with a role (client, adverse party, related entity, witness) and a link back to every matter that party appears in.
Once that registry exists, a conflicts check stops being a search through history and becomes a lookup against a single, current, purpose-built list. This is the same move the MATTER Method makes everywhere else: stop treating the thing you need as scattered evidence inside other containers, and give it one container of its own.
The testCan you produce, in under a minute, every matter a given name has ever touched in any role - without opening a single matter file?
Actions - name the sequence, including the two steps everyone skips
Capture the parties. Screen against the registry. Screen against adverse history. Flag near-matches. Escalate ambiguity to a named decider. Log the outcome. Re-trigger on any new party added mid-matter.
Most informal conflicts processes have exactly one action: 'check for conflicts', performed once, at intake. Written out properly, the sequence has at least seven distinct steps, and the two most commonly skipped are the last two.
Logging the outcome matters because an undocumented 'no conflict found' is indistinguishable, a year later, from a check that never happened. Re-triggering on new parties matters because conflicts do not only arise at intake - a third party joins a dispute, a counterparty turns out to be a subsidiary of an existing client, a witness becomes a co-defendant. A conflicts process that only runs once, at matter opening, has a structural blind spot for everything that happens afterward.
The testDoes your process re-run automatically when a new party is added to an open matter, or does it depend on someone remembering to ask?
Time - make the check fast enough that nobody is tempted to skip it
The check has to run before the engagement letter goes out, every time, and it has to be fast enough that speed is never the reason it gets shortcut.
A conflicts check that takes three days does not stay a three-day process. It becomes a step people work around, because a client wants an answer today and the alternative is losing the instruction. This is where duration data matters as much here as it does in pricing: once a registry-based lookup for a clean match takes minutes rather than days, there is no longer a commercial incentive pulling against running it properly.
Ambiguous matches are the exception, and they should be allowed to take longer, because that is where the judgment genuinely belongs. The design goal is not 'every check is instant'. It is 'the routine case is instant, and the exceptional case is visibly routed to someone with the authority to decide it, on a defined timeline'.
The testDo you know how long a routine conflicts check actually takes today, measured, not estimated?
Team - a doer, a reviewer, and one named decider for ambiguous matches
The first pass, human or agent, is the doer. A second person confirms a genuine near-match before it is escalated. One named partner - not 'whoever is free' - decides what happens with a real conflict or a waiver request.
Informal conflicts checking usually has an implicit decider: whoever happened to run the search. That is precisely the arrangement that produces inconsistent outcomes, because the person best placed to run a fast first-pass search is rarely the person with the authority, or the full picture across the firm, to decide what an ambiguous match should mean for the engagement.
Naming the decider explicitly, in writing, before any automation is introduced, does the same work here that it does everywhere else in the MATTER Method: it is what makes delegating the first pass to an agent safe later, because the escalation path already exists independently of who or what produced the flag.
The testIf a first-pass check flags an ambiguous match today, is there one named person who decides what happens next, or does it depend on who happens to see the flag?
Evidence - anchor every decision, including the clean ones
Every conflicts outcome, cleared or escalated, carries a record: which records were searched, what matched, on what date, and who signed off.
This is the primitive most conflicts processes skip entirely, because a 'no conflict found' feels like it needs no record. It is exactly the record that matters most, because it is the one a regulator, an opposing party, or a court will ask for if a conflict surfaces later and the firm needs to show what was actually checked and when.
The anchoring standard is identical to the one this studio applies to drafting: no assertion - 'no conflict exists' is an assertion - ships without a checkable source behind it. What was searched, against what registry, on what date, by whom.
The testFor a matter opened six months ago, can you produce the record of exactly what the conflicts check searched, not just that one was 'done'?
Research - let past waiver decisions compound instead of resetting
A conflict waiver reasoned through once should never need to be re-reasoned from zero the next time a structurally similar situation arises.
Firms that handle conflicts well over time are not the ones with the strictest rules. They are the ones whose past reasoning on genuinely close calls is retrievable, so a partner facing a similar fact pattern this year can see how the firm reasoned through the last one, rather than starting the ethical analysis from a blank page under time pressure. That is the research primitive applied to governance rather than to legal substance, and it is just as real an asset.
The testIf the same kind of near-conflict came up twice, would the second decision benefit from the first, or would it be reasoned through again from scratch?
Where automation actually fits
A bounded agent, not an autonomous one.
Once the registry exists, the sequence is named, and the escalation path is explicit, a conflicts-screening agent has something to grip. Its job is narrow and specific: take the incoming parties for a proposed new matter, run a fuzzy match against the party registry - names, known variants, related entities where that data exists - and produce a ranked list of possible matches with a confidence indicator on each.
What the agent must never do is clear a matter on its own or decline one on its own. It flags. A human, specifically the named decider from the Team primitive, resolves anything above a defined confidence threshold, and every clean, no-match result still gets logged with what was searched, so the record exists regardless of outcome. This is the same bounded pattern that runs through every agent this studio deploys: the machine does the first pass, on a task that has already been named and systematised, and a named person remains the one who decides and is responsible for the result.
The failure mode this redesign closes is not 'the firm missed an obvious conflict'. It is 'nobody could show, months later, what was actually checked' - and that failure mode disappears the moment the check has a container, a sequence, and a record, before a single line of automation is written.
Questions, answered plainly
Why does conflicts checking need a redesign rather than just more discipline?
Discipline does not survive being tired, busy, or new. A process that depends on one person's memory of forty prior matters is not a process, it is a hope that the right person is paying attention on the right day. Structural fixes - a separate party registry, a named sequence, a named decider - survive staff turnover, busy weeks, and new hires in a way that a reminder to 'be careful' never will.
Is it safe to let an AI agent run a conflicts check?
Yes, for the first pass, inside a bounded role. The agent screens against the firm's own party registry and flags possible matches with a confidence score. It never clears a matter and never declines one on its own - a named person makes that call, every time, and the outcome is logged regardless of which way it goes.
What is the single highest-leverage change a small firm can make to conflicts checking this month?
Build the party registry as its own container, separate from individual matter files, and start logging every conflicts outcome, including the clean ones, with what was searched and when. Both changes require no new software and no AI at all, and they are the foundation everything else in this teardown depends on.
How is this different from what most practice management software already does?
Most practice management software offers a search box across whatever data it already holds, which is only as good as the party data entered into that specific system. The redesign here is definitional first: deciding what counts as a party, building one registry that spans every matter type and every role a party can hold, and naming the escalation sequence - a discipline that has to exist before any search box becomes trustworthy, in any software.