Matter, client, and conflicts data inside the privilege boundary

A partner wants to take on a new client: a mid-size manufacturer suing a supplier. Before anyone signs an engagement letter, the firm must answer a deceptively hard question: have we, at any point, in any office, represented that supplier, its parent, a subsidiary, a board member, or an adverse party who might now be helped or hurt by this new work?

That single question, the conflicts check, forces a law firm to model its data in a way no retailer, bank, or SaaS company ever has to. This lesson explains why.

What a "matter" actually is

In law firms, work is organized around the matter: a discrete piece of legal work for a client. A single client can have hundreds of matters (a lawsuit, a merger, a patent filing, a routine contract review).

The core entities are simple to name:

• Client: the party the firm represents.
• Matter: the specific engagement.
• Party: everyone connected to a matter (opposing parties, co-defendants, witnesses, related companies, individual officers).

The complexity is in the last one. A conflicts check does not compare client to client. It compares every party on the new matter against every party the firm has ever touched.

Why the conflicts check breaks the normal data model

Most businesses ask "who are my customers?" A law firm must ask "who is everyone we have ever been adverse to, on behalf of anyone, ever?"

Ethics rules require this. In the United States, the ABA Model Rules of Professional Conduct (Rules 1.7 and 1.9) prohibit representing a client whose interests are adverse to a current or former client without informed consent. Similar duties exist under the SRA in England and Wales and most other bar regulators.

That means the conflicts database is effectively permanent and all-inclusive. You cannot delete a former client. You cannot ignore the opposing party from a matter you lost ten years ago. Every name is a potential future conflict.

So the firm keeps a growing graph of parties and relationships, and queries it against every new engagement. This is the opposite of the "keep only what you need" instinct that governs most modern data hygiene.

Entity resolution: the real technical problem

The hardest part is that names are messy. "Acme Corp," "Acme Corporation," "ACME Corp. (Delaware)," and "Acme Holdings" may or may not be the same entity. A conflict can hide in any of them.

Entity resolution (also called record linkage or deduplication) is the practice of deciding when two records refer to the same real-world thing. In a conflicts system this is not academic. Miss a match and the firm may accept a disqualifying conflict. Over-match and every check drowns in false positives that partners ignore, which is how real conflicts slip through.

A simplified matching pass looks like this:

# Illustrative only: fuzzy name matching for a conflicts pre-screen
from rapidfuzz import fuzz

def is_possible_match(name_a, name_b, threshold=88):
    score = fuzz.token_sort_ratio(
        name_a.lower().strip(),
        name_b.lower().strip()
    )
    return score >= threshold

is_possible_match("Acme Corporation", "ACME Corp.")  # -> True (flag for human review)

The output is never a decision. It is a flagged list a conflicts analyst reviews by hand. In law firms, the human in the loop is not optional; it is the control.

Good entity resolution also needs corporate family trees. If your client is adverse to a small subsidiary, you may be adverse to the whole parent group. Firms often license corporate hierarchy data or maintain it manually, because "who owns whom" changes constantly through acquisitions.

Ethical walls: segmentingsegmentingDividing a market into distinct groups of customers who share similar needs, characteristics or behaviours, so each group can be served with a tailored approach.View full definition → data on purpose

Sometimes a conflict exists but the firm can still take the work by isolating information. This is an ethical wall (also called a screen or an information barrier): a set of controls that prevents lawyers on one matter from accessing another matter's confidential data.

Example: the firm represents Company A in litigation. A lawyer who once worked at another firm and briefly advised the opposing party joins. To keep the engagement, the firm screens that lawyer: no file access, no billing entries, no hallway conversations about the matter.

In data terms, an ethical wall is row-level and document-level access control tied to individual users, not to roles or departments. Most enterprise software assumes access follows job function. Legal software must support "these three named people cannot see this one matter, forever, even though their title says they could."

🎬 [VIDEO: "What Is a Conflict of Interest for Lawyers?" — youtube.com — a short, plain-language explainer of legal conflicts and screening]

Privilege and confidentiality: why cloud analytics gets complicated

Here is where the data lens gets sharp.

Attorney-client privilege protects confidential communications between a lawyer and client from being disclosed, including in court. Confidentiality (the ethical duty) is broader and covers essentially everything the firm learns about a client. Both create a privilege boundary: a line around client data that the firm must not let leak.

That boundary rules out patterns other sectors treat as routine.

Pooling data across clients. A retailer happily blends all customer behavior into one analytics warehouse. A firm generally cannot pool one client's matter data with another's for analysis, because that mixing itself can breach confidentiality and, in some readings, waive privilege.

Third-party cloud processing. When client data flows to an external analytics or AI service, the firm must ensure the vendor cannot use, retain, or expose it. Many firms require contractual guarantees of no training on their data, tenant isolation, and specific data residency. Some engagements (government, financial, defense clients) prohibit cloud processing entirely by client mandate.

Generative AI tools. A public chatbot that logs prompts is a confidentiality risk if a lawyer pastes in client facts. Bar associations have issued guidance; see the ABA Formal Opinion 512 on generative AI (2024) for the reasoning. The short version: lawyers stay responsible for confidentiality no matter what tool they use.

The practical result: law firms often run analytics and AI inside their own controlled environment, not on shared multi-tenant platforms, and they apply the ethical wall model to their data pipelines too.

How firms actually structure the data

Put the pieces together and a workable model emerges.

A conflicts graph, not a customer table. Parties are nodes. Matters connect them. Relationships (parent, subsidiary, officer, adverse, co-counsel) are edges. A conflicts check is a graph query: find all paths between the new parties and any existing party.

Aggressive metadata, careful content. The firm can freely track structured metadata (client number, matter number, party names, dates, responsible partner) in searchable systems. The privileged content (the actual advice, documents, communications) sits behind stricter access controls and stays segmented by matter.

Access as a first-class field. Every document and matter carries an access list. Ethical walls are enforced in the system, logged, and auditable, because a regulator or opposing counsel may later demand proof the screen held.

Retention that fights deletion. Conflicts data is kept indefinitely. But privileged matter content often has retention schedules driven by malpractice risk and client agreements. These two impulses (keep the names forever, dispose of the substance on schedule) coexist in the same firm.

A quick contrast makes the point:

Why this matters for anyone working with legal data

If you build, buy, or analyze data systems for a firm, the instinct to "centralize everything and run analytics on top" is exactly wrong. The privilege boundary and conflicts obligations are not IT preferences. They are ethical duties enforced by bar regulators, with disqualification, malpractice exposure, and reputational damage as the penalties.

The firms that get this right treat conflicts as a graph problem, entity resolution as a human-supervised process, and ethical walls as a data control, not a policy memo.

Key Takeaways

• A law firm's data model is built around matters and parties, and a conflicts check compares every party on new work against every party the firm has ever touched, which makes the database permanent and all-inclusive.
• Entity resolution (matching messy names and corporate family trees) is the core technical challenge; automated matching only flags candidates, and a human analyst makes the call.
• Ethical walls require access control at the level of named individuals per matter, not the role-based access most software assumes.
• The privilege boundary rules out cross-client data pooling and unrestricted cloud or public AI processing that other sectors take for granted.
• Retention pulls two ways: keep conflicts names forever, but dispose of privileged content on schedule.