The Duplication Trap | Part 1 of 3 | When your systems use different names for the same entity, resolving the duplicates looks like the ultimate fix. That's the trap: the records line up, but everything connected to them stays invisible. Three posts on why that happens, what it costs, and how to decide with the full picture.
TL;DR
Enterprise systems name the same customer, supplier, or product in different ways. An entity resolution platform confirms which records belong to the same entity, using rules, graphs, knowledge graphs, or LLMs. That solves identity. It doesn’t show where that entity is represented across the IT ecosystem, which systems and processes are connected to it, or what could be affected by changes around it. That missing layer is the context layer.
In this Article
The Problem: One Entity. Multiple Names.
Most companies like to think their systems have a consistent view of the entities they work with. But in practice, the same entity shows up differently in every system. A CRM has a customer called “Acme Corp.” Finance calls the same company “ACME Corporation Ltd.” Support just knows it as ID “ACM-004.” Same customer, three names, zero connection between them.
Now ask yourself: is the same thing happening with your suppliers? Your products? Your employee records? For most large companies, the honest answer is probably yes.
This is where an entity resolution platform usually gets pitched as the fix. And it solves an important part of the problem. But resolving identity doesn’t reveal everything connected to that entity across the enterprise.
This article walks through what entity resolution actually is, the techniques companies typically reach for, and what the real solution looks like once identity alone stops being enough.
Entity Resolution Meaning: From Duplicate Records to Business Entities
Here’s what is entity resolution in plain terms: the process of determining that records from different systems, however different they look on paper, actually describe the same real-world entity.
That covers more than customer records. Entity resolution matches:
- Customers — The same account, named differently in every system that touches it.
- Suppliers — One vendor, multiple IDs across procurement, finance, and operations.
- Employees — A single person, fragmented across HR, payroll, and access systems.
- Products — One SKU, described inconsistently across catalog, inventory, and billing.
Why does this happen? Your systems weren’t built together. Your CRM was probably set up years before your billing platform. A different team built your support tool. Each one invented its own naming conventions, its own IDs, its own rules for what counts as a valid record.
Multiply that across every system touching your enterprise data, and you don’t get one clean version of an entity. You get several, scattered across your enterprise databases, each one missing part of the picture.
The Entity Resolution Problem in Enterprise Data
Now scale that up. A large company doesn’t have three systems, it has dozens:
- Legacy tools nobody dares to touch, quietly building legacy system risk with every year they stay unexamined.
- One system per department, each with its own naming logic and its own definition of “customer”.
- A handful more with every acquisition, each one a different company’s version of the truth
This isn’t a “messy data” problem you can shrug off. It’s an entity resolution problem with real costs: reports that don’t match, integrations that break, forecasts nobody trusts, audits that take twice as long as they should. Data reconciliation across all these systems only works if everyone agrees on what “the same customer” means. Right now, most companies don’t have that agreement.
Entity Resolution and Data Deduplication: What's the Difference?
People often confuse entity resolution and data deduplication, but they’re not the same job:
Concept | What it means | Example |
Data deduplication | Cleans up one system: finds identical rows in the same database and merges them. | Two duplicate order entries in one sales database. |
Entity resolution | Connects the same real-world entity across completely different systems, even when records don’t look alike. | “Acme Corp” in the CRM and “ACM-004” in billing |
The missing layer | Identity is resolved, but nothing shows which applications and processes are connected to that entity, or what could be affected by changes in the systems around it. | The customer is confirmed as one entity, but no one can say which pipelines and reports would break if its ID format changed. |
Say your CRM has zero duplicates. Finance and Support can be just as clean and still describe the same customer three different ways. Data deduplication can’t see that problem, because it only looks inside one system. Entity resolution can. What it can’t show is how that entity is represented across the IT ecosystem once the records are matched: the applications, processes, and dependencies connected to the systems around it.
Today, companies try to solve this somewhere between two extremes: exact-match rules that break the moment a name is written differently, and AI models that fill the gaps with confident guesses.
4 Entity Resolution Techniques: From Rules to AI
There are a few different entity resolution techniques for doing the matching.
1. Rule-Based Entity Resolution
The simplest approach: if two records share a tax ID, an email, or an exact name match, the system links them. It works well when your data is tidy. It breaks fast the moment someone types “ACME Corp.” instead of “ACME Corporation Ltd.”
2. Graph-Based Entity Resolution
Graph-based entity resolution looks past the name and at the relationships instead: same billing address, same contract, same account manager. Even if “Acme Corp” and “ACM-004” share nothing in their name fields, sharing five other connections is a strong sign they’re the same company.
3. Knowledge Graph Entity Resolution
Knowledge graph entity resolution takes that further, using knowledge representation to map how every entity connects to every other one, not just in pairs, but across the whole business.
4. LLM Entity Resolution
LLM entity resolution can help with the messy, ambiguous cases, like guessing that “A. Corp” and “Acme Corporation” probably refer to the same thing. It’s useful for catching patterns a rule would miss. It’s not a source of guaranteed truth on its own, and treating it like one is how new, invisible errors sneak into your data.
Every one of these entity resolution techniques answers the same question: are these records the same entity? Once the answer is yes, a harder one shows up. Do you actually know how the systems around that entity are built and connected, or is most of that still invisible? The usual reflex is to pull everything into one place and hope the full picture appears.
Why a Data Lake Doesn't Solve the Invisibility Problem on Its Own
The obvious fix looks simple. Dump everything into one place:
- A data lake.
- A data cloud platform.
- A warehouse.
Problem solved, right? Not quite.
Moving data into one place doesn’t make it agree with itself. Centralizing data just means your fragmentation problem now lives in one very large room instead of five small ones. A data lake or a warehouse can hold every record you own. It still isn’t a single source of truth architecture, because consolidation moves data, it doesn’t reconcile what that data means.
Having everything in one place isn’t the same as understanding how it fits together. So the natural next move is an entity resolution platform. It sounds like the fix. But it isn’t the full one.
What Does an Entity Resolution Platform Actually Solve?
An entity resolution platform is designed to solve a specific problem: determining whether different records belong to the same entity. Acme Corp, ACME Corporation Ltd, and ACM-004 go in. One resolved customer comes out.
That’s real value. Cleaner records, less duplication, more trustworthy reporting. Nobody should skip this step. But resolving an entity’s identity isn’t the same as understanding that entity.
Where Entity Resolution Stops
Resolving identity closes one gap and opens a bigger one. Once the same entity is confirmed across every system that mentions it, a different set of questions takes over:
- Where is this entity actually represented across the IT ecosystem?
- Which applications and processes are connected to it?
- What breaks elsewhere by changes in the surrounding architecture?
Knowing that different records describe the same entity answers none of these. Identity and structure are two different problems, and solving one doesn’t solve the other. Entity resolution confirms what something is. It was never built to reveal the layer underneath: where that entity is represented, which systems and processes are connected to it, and how it fits into the wider IT ecosystem.
That missing layer has a name.
The Missing Layer is The Context Layer
Context can mean almost anything inside a company. Culture, history, tribal know-how, strategy. That’s too broad to be useful. For an enterprise’s technology ecosystem specifically, context means something concrete: the real structure underneath everything that runs the business:
- Every system, and what it actually does today, not what it was built to do five years ago.
- Every application, and how it’s wired into the rest of the stack.
- Every dependency, so nothing breaks silently when something upstream changes.
- Every connection between them, the relationships that never made it into any diagram.
Pulling all of that into one reliable source is what a context layer is supposed to do in enterprise IT. But not every context layer gets this right. Some rely on AI models that hallucinate or infer relationships that were never confirmed. Others depend on someone documenting what they remember, which is interpretation, not reality. Not because people do their job badly, but because memory and interpretation are natural limits on how much structure a person can actually capture.
The good news: much of that structure already exists in the systems themselves. It can be extracted directly from the technology that runs the business, rather than reconstructed from memory or interpretation. A real context layer should read that structure directly: how your CRM, your data lake, your entity resolution platform, and everything else are actually built, and how they actually relate. Without that, even a perfectly resolved entity is floating with no clear picture of what it’s connected to.
Why AI Agents Are Hungry for Real Context
The stakes get higher the moment AI agents start working with that resolved entity. An agent that inherits a clean, resolved customer entity still may not know how that entity is represented across the IT ecosystem or what systems are connected to it. Without that context available upfront, it may need to explore, query, and reconstruct those relationships itself.
According to McKinsey’s 2026 State of AI survey of 1,719 executives, 1 in 5 organizations already say operating costs, including tokens, are constraining their AI use. Here’s where that cost can show up: the moment an agent has to work with enterprise customer information without knowing how that entity is represented across the systems around it. It may need to explore, query, and reconstruct those relationships itself just to understand what the entity is connected to.
From Entity Resolution to Enterprise Context
Enterprise systems can disagree on what an entity is, where it is represented, and how it connects to the wider IT ecosystem. Entity resolution solves the first problem, but not the others. This is where Velorum comes in.
Velorum makes the structure behind those entities visible:
- Applications
- Dependencies
- Connections and relationships.
- Cloud infrastructure.
That context is built directly from the systems, not reconstructed from documentation or assumptions. It is deterministic, traceable back to the underlying code, and continuously updated as the systems change.
Entity Resolution Platforms Solve Identity. Velorum Makes the Whole Ecosystem Visible.
Some entity resolution techniques already use a graph, mapping relationships between records to guess whether they’re the same entity. That’s still identity resolution, and when it leans on AI to make that call, it’s probabilistic, built to answer one question, and working entirely on business data.
Velorum works differently. It deploys directly in your stack and builds a deterministic graph of relationships:
- Velorum reads the real structure of the ecosystem: systems, applications, dependencies, and how they connect.
- It pulls that structure directly from the infrastructure itself, not from inference or assumption.
- That knowledge graph is what powers everything Velorum does: automated software documentation, impact mapping before any change, and answers to plain-language questions about your systems.
In the specific case of entity resolution, Velorum’s graph shows the technology surrounding an entity once its identity has been resolved:
- Which applications contain or use the entity.
- Which systems represent it.
- Which applications and processes are connected to those systems.
- What could be affected by a change in the surrounding architecture.
That’s what it actually means for the IT ecosystem to become visible and actionable: not just the entities an entity resolution platform has already resolved, but every system, application, and dependency around them, resolved or not.
The Velorum Suite
An entity resolution platform decides, at the record level, that customer 12345 in the CRM and customer ABC in the ERP are the same. Velorum addresses a different layer of the problem. It knows a “Customer” entity exists in both the CRM and the ERP, and how the two relate: the map of where each business concept actually lives, not the row-by-row matching itself.
The Velorum Suite, the applications that unlock the knowledge graph Velorum builds, answers exactly that.
| Entity resolution platform | Velorum | App | |
|---|---|---|---|
| Core question | Are these records the same entity? | Where is that entity represented, and what systems and applications are connected to it? | — |
| Operates on | Business records | System structure and metadata, never business data | — |
| Shows where an entity lives across systems | No | Yes | Knowledge Documentation |
| Shows which applications and processes could be affected by changes in the surrounding systems | No | Yes | Impact System Mapper |
| Answers plain-language questions about the system, dependencies included | No | Yes | Navis |
An entity resolution platform can tell you a record is real. Velorum can tell you everything it touches, before it becomes the reason something breaks.
Final summary
Entity resolution answers one question: are these records the same entity? It’s a necessary step, but identity isn’t structure. Once an entity is resolved, teams still can’t see which applications use it, which processes depend on it, or what breaks if it changes. An entity resolution platform can tell you which records represent the same entity. Velorum can show how that entity is represented across the IT ecosystem and what systems and applications are connected to it.
Further Questions
Can Velorum explain why two systems or entities are considered connected?
Yes. Every relationship in the knowledge graph is explicit and traceable back to its source, never a confidence score from a black-box match. That makes it possible to audit exactly why two things are linked, case by case, whether the answer comes as a plain-language explanation through Navis or as a visual impact map through Impact System Mapper.
Is Velorum a replacement for an entity resolution platform, or just a complement to one?
Neither. Velorum builds its knowledge graph independently, straight from your systems’ real structure: applications, dependencies, infrastructure, code, with or without an entity resolution platform in the picture. Knowledge about a confirmed entity match can inform the graph as well, one more piece of structure alongside everything else Velorum already maps on its own.
Does using Velorum put my company's data at risk?
No. Velorum never accesses your company’s business data. It only reads structure and metadata: schemas, code, configurations, and how your systems connect to each other. Customer records, financial data, operational data, none of that enters the graph, only the structure around it. That’s also what makes it safe to put in front of architecture, governance, security, and business teams alike.
