Before You Can Reason, You Have to Know Who Is Who

An ontology tells us what class of thing each record is. But in the real company, the same entity appears under ten different names. Until we resolve that, any reasoning over enterprise knowledge is built on sand.

Introduction

Yesterday we defined the ontology as the explicit specification of a domain: classes, relations, constraints. But there is a problem the ontology does not solve on its own, and that appears in the first meeting with any data team: which concrete entity does this record represent?

Because in the real company, “ACME” is not an entity. “ACME,” “ACME LTD,” “ACME UK,” “Acme Group,” “Customer #49281,” and “ACME (UK) Ltd — Manchester office” can be, depending on the system and the moment, the same entity, two different entities, or one entity with two subsidiaries. And until we know which of the three is the reality, we cannot reason about anything.

The problem

A financial institution is building a compliance agent for KYC/AML (Know Your Customer / Anti-Money Laundering). The agent has to answer questions like “Does this customer have any relation to an entity on a sanctions list?” or “Which group does this customer belong to?”

The problem: the customer they call “ACME” appears in its systems like this:

They are six records. Is it one entity or six? The correct answer, which only the KYC analyst knows, is: one parent entity (ACME Group) with two subsidiaries (ACME LTD and ACME UK Ltd), of which one has an account in its name and the other operates as a correspondent. And that structure is exactly what the agent needs to answer the sanctions question correctly.

If the agent treats the six records as six different customers, it will say that “ACME UK” has no relation to “ACME Group” and it will pass a sanctions check that should have stopped it. If it treats them as a single customer, it will mix up risk profiles that are different and it will generate false positives that will saturate the compliance team.

In both cases, the agent did not reason badly. The identity of the entities was not resolved, and on that identity everything else was built.

The concept

Entity Resolution is the process of identifying, unifying, and maintaining the identity of real-world entities across multiple data sources. It has three fundamental operations:

1. Matching. Deciding whether two records, possibly from different systems, refer to the same real entity. “ACME LTD” and “ACME UK LIMITED” — same entity or two?
2. Deduplication. Unifying the records that correspond to the same entity into a single canonical representation, preserving the traceability of where each datum came from.
3. Identity over time. Maintaining the identity when the entity changes its name, merges, splits, or restructures. “ACME Group” bought “Beta Corp” in 2024: now they are one entity, but their histories are different.

Entity resolution is not a string problem. “ACME LTD” and “ACME UK LIMITED” look alike, but “ACME” and “ACME & SONS” do not. And sometimes two different entities look a lot alike (two “Acme” companies in different jurisdictions). The methods range from the simple (normalization + name similarity + matching on attributes like tax ID) to the complex (supervised learning models over annotated pairs, reasoning over relation graphs). But the principle is the same: deciding what is the same thing, with evidence and with traceability.

And here is the key point for the series: entity resolution is a prerequisite of reliable enterprise knowledge. Without it:

• The ontology (yesterday) cannot be applied: you do not know which concrete entity to assign the class to.
• The relations (tomorrow) cannot be built: you do not know who relates to whom.
• The knowledge graph (in the coming days) becomes a graph of duplicates: six nodes for the same company, each with a part of the history.
• And the agent, instead of reasoning about the company, reasons about a collection of records it does not know whether they are the same thing.

Architecture

In the series diagram, entity resolution sits just above the semantics and below the knowledge, as the process that turns records into entities:

                KNOWLEDGE
                     ↑
          ┌──────────┴──────────┐
          ↓                     ↓
      ONTOLOGY          ENTITY RESOLUTION
   (classes, relations,   (matching, dedup,
    constraints)           identity) → ENTITIES
          ↓                     ↓
          └──────────┬──────────┘
                     ↓
                SEMANTICS
                     ↓
                   DATA

The ontology says what class of thing it is; entity resolution says which concrete thing it is. Together, they produce the canonical entities on which the rest of the knowledge is built.

Use case

The financial institution, with its KYC/AML case. We break it down:

1. Problem. The sanctions check and the customer-group analysis depend on knowing who is who, and today that information is scattered across six systems with inconsistent names. An identity error can mean a regulatory violation or, at the other extreme, a false positive that blocks a legitimate customer.
2. Decision. Determine the group a customer belongs to and whether any member of the group is on a sanctions list.
3. Necessary knowledge. Which entities make up the ACME group; which is the parent entity and which are the subsidiaries; what relation (ownership, correspondent, account) exists between them; which entity is on the sanctions list.
4. Data. The six records in the table, plus the tax ID, the commercial registry, the ownership structure (in a groups system), and the sanctions lists (external).
5. Relations. ACME Group → owns → ACME LTD; ACME Group → owns → ACME UK Ltd; ACME UK Ltd → has account → Customer #49281; ACME UK Ltd → appears on → sanctions list.
6. Context. The query is made by the compliance team (high permissions); the sanctions list was updated 3 days ago; there is an open investigation on the ACME group.
7. Memory. The ACME group was investigated last year for a suspicious operation; the conclusion and the owner are in the case history.
8. Reasoning. Unify the six records into the ACME group; traverse the ownership relations; check that ACME UK Ltd is on the sanctions list; conclude that the group has an exposure.
9. Action. Alert the compliance team with the chain of evidence (which records were unified, which relation, which entry in the list); open the case.
10. Infrastructure. Entity resolution (unifying the six records into the group) + graph of ownership relations + the sanctions lists as an external source + the memory of the prior case + the traceability of the whole chain. Without entity resolution, the chain starts broken.

The case demonstrates the rule: the technology (graph, agent) appears as a consequence of the need (knowing which group a customer belongs to for a sanctions check), not as a starting point.

Trade-offs

• Cost. Quality entity resolution is expensive: it requires reliable attributes (tax ID, commercial registry), annotated pairs to train models, and a human review process for the edge cases.
• Complexity. The edge cases (two real “Acme”s, a merger, a split) are not solved with a rule: they require judgments that have to be documented and maintained.
• Accuracy vs. coverage. A strict matching threshold produces few false positives but leaves duplicates (low coverage); a loose threshold unifies well but mixes different entities (false positives). In compliance, the error of mixing two different entities is more expensive than the error of leaving a duplicate.
• Maintenance. Entities change: they are renamed, merged, split. The canonical identity has to be updated or the graph is silently corrupted.
• Traceability. Each unification has to be auditable: which records were joined, why, with what evidence, and who approved it. In regulated environments, an unification without traceability is a violation in waiting.
• Honest limitation: entity resolution resolves the identity of the records that exist. If the entity does not appear in any system (an informal supplier, a cash entity), the process cannot create it. It works with what is there; it does not invent what is missing.

Implication for the business

For the CDO, entity resolution is the organization’s identity asset: the answer to “who are our customers, suppliers, and counterparties, really?” And it is an asset that, today, in most companies, does not exist as such: it exists as a collection of inconsistent IDs.

For the compliance team (and in general, for any regulated function), entity resolution is what turns a “search the name in a list” check into a “traverse the group and its relations” check. The difference is the difference between a false negative and a real detection.

For the executive team, the message is one of risk: every decision an agent takes about a customer, a supplier, or a counterparty depends on the identity of that entity being resolved. And today, in many cases, it is not.

Conclusion

Entity resolution is the prerequisite of reliable enterprise knowledge: without knowing which concrete entity each record represents, the ontology cannot be applied, the relations cannot be built, and the agent reasons about a collection of duplicates. Today we have seen it as the bridge between the semantics (what class of thing) and the knowledge (which concrete thing, and how it relates).

And that leads us to the next piece: now that we know who is who, how do they relate? Because the business, remember, does not live in isolated entities. It lives in what connects them.

Next article

Tomorrow: Data describe entities. The business lives in its relations. We will see why a chain like “customer → owns → contract → covers → product → depends on → component → supplied by → supplier” is more than an engineering curiosity: it is the map where the business really is.

Sources

• Working definition of the ECI: see the series, Day 1.
• Entity resolution is a classic problem of data integration and record linkage; it is presented here in operational terms for enterprise and regulated environments.