Identity Resolution and Entity Mastering for the Enterprise Context Layer

Updated October 2026

Entity mastering turns matched records into one governed entity that every system can trust. It picks a winning value for each attribute, assigns a stable ID, sends doubtful matches to people, and keeps the entity correct as sources change. Identity resolution finds the matches, and mastering decides what the business believes about them and how it serves that belief.

What does entity mastering add on top of entity resolution?

Mastering adds decisions, ownership, and time. Resolution answers whether two records describe the same thing. The entity resolution glossary entry covers how that matching works, from blocking to Fellegi-Sunter scoring to LLM judges. This guide starts after the match score exists.

Three questions remain once records are linked. Which value of each attribute should the business trust? Which ID will every downstream system store? Who fixes a wrong merge, and how fast? An enterprise context layer needs answers to all three before analytics, search, and AI agents can rely on it.

Skipping mastering is common. Teams link records in a notebook, pick a primary system, and call it done. Each consumer then picks its own winning values, and the company ends up with several customer counts again.

How do you design survivorship rules for a golden record?

Set survivorship per attribute, not per record. A customer's legal name might come from the ERP, the phone from the CRM, and the address from a verified enrichment source. Each attribute follows the rule that fits how that data is created and maintained.

Reltio's survivorship documentation lists more than ten strategies. The default is last update date. Others include source system priority, frequency across sources, oldest value, min and max value, aggregation that keeps every value, and custom strategies. That list is a useful checklist even if you build on your own stack.

Two habits keep survivorship healthy. Store which rule picked each value and which source supplied it, so a reviewer can answer why a field looks the way it does. Review the rules on a schedule driven by data quality signals, because the most trusted source today may decay after a migration.

Survivorship should never touch the ID. Recalculating which phone number wins is routine, and it must not mint a new entity.

Should you master entities in an MDM hub or a graph?

Use a hub when operational systems need clean records written back, and a graph when relationships carry the evidence. Most mature programs end up with both around the same stable ID. The choice is about who consumes the entity and how much the links matter.

Hubs follow well-known implementation styles. Reltio's overview of MDM styles names four of them. Registry indexes sources quickly at low cost. Consolidation adds steward review. Coexistence writes golden values back to sources, and centralized makes the hub the only place data is authored. Each style trades speed for control.

Graph-based mastering treats records and shared identifiers as nodes. Neo4j describes using Weakly Connected Components and Node Similarity to group records that share emails, phones, or addresses. It calls WCC fast and scalable but best suited to data where identifiers cleanly segment entities. Messier data needs similarity thresholds or link prediction on top.

A practical split works well. Let the hub own golden attributes and approvals. Let the graph hold source records, match evidence, and relationships to other entities, keyed by the same ID. The graph also feeds the knowledge graph platforms many teams already run.

How do you keep entity IDs stable?

Keep IDs in a registry that is separate from the matching engine. Many tools derive IDs from the current cluster or from load order, so IDs drift when data changes. Every report, cache, and agent memory that stored the old ID then breaks quietly.

Vendor documentation shows why this needs design work. Senzing's exploration tutorial warns that entity ID values depend on load order. Tamr keeps a mapping from source keys to Tamr IDs between refreshes. It still assigns new IDs when source keys or dataset names change, or when new matches reshape a cluster.

A registry pattern avoids most of this. It stores source system plus source key, the permanent entity ID, and a history table of merges and splits. Four rules make it work.

1. When clusters merge, keep the oldest ID and record the other as an alias that redirects.

2. When a cluster splits, the larger side keeps the ID and the smaller side gets a new one, with both events logged.

3. Never compute the ID from a hash of cluster members or attribute values.

4. Publish merge and split events so downstream systems can update stored references.

AWS Entity Resolution shows a related idea in its transitive matching option. There a record's match ID is fixed on its first match even as later rules add records to the group.

How should the stewardship workflow run?

Route only the uncertain middle band to people, and give them the evidence in one view. IBM Master Data Management documents the standard two-threshold design on a score from 0 to 100. Scores above the autolink threshold merge automatically. Scores between that and the clerical review threshold are queued for data stewards, and scores below stay separate.

Start with a high autolink threshold. A false merge mixes two customers' histories, permissions, and revenue, and the error spreads to every consumer before anyone notices. A missed match is usually cheaper to catch and fix. Lower the line only once unmerge and post-merge checks are proven.

A good review task shows the two records side by side, the score, the rule or features that drove it, and the survivorship values a merge would produce. Senzing's why and how commands are a good model, since they show the features and resolution steps behind a decision. Stewards who cannot see the reasoning end up approving everything or nothing.

Unmerge has to be a first-class path. Reltio's match and merge documentation notes that match rules keep a unique URI per entity so merges can be undone. Its matchBeforeCreate option merges on load and cannot be unmerged later. Whatever the tool, keep source records intact and run merged entities through a context QA gate before serving them.

How do you serve resolved entity IDs to AI agents?

Give agents a resolve step that turns names into stable IDs, then let every other tool take the ID. An agent asked about "Acme" should first get back one entity ID, a confidence score, and the source records behind it. Every later query for orders, tickets, or contracts then filters by that ID.

This is where the enterprise context layer earns its keep. Without resolution, an agent's search returns whichever duplicate ranks first. With it, the agent sees one supplier with its full history and its relationships to contracts and contacts.

MDM vendors now expose this through the Model Context Protocol, which Anthropic donated to the Agentic AI Foundation in December 2025. Reltio introduced an MCP server in June 2025 that lets agents search profiles, review matches, and update entities. Senzing runs an MCP endpoint focused on mapping data, writing SDK code, and building evaluations.

Three rules keep agent access safe. Return the stable ID, never a source key. Return confidence and provenance with every resolved entity so the agent can cite it. Keep write actions such as merge or update behind the same steward approvals people use.

Mastered entities are institutional knowledge. Match rules, survivorship choices, and steward decisions should live in open formats on infrastructure the company controls, not only inside one vendor's hub.

Galaxy is an applied lab that builds this layer with teams on the stack they already run, using internal tooling for entity resolution, ontologies, and semantic models. It builds in the open with Filament and plans to open source more of that tooling.

Which metrics show entity mastering is working?

Measure match quality at both pair and cluster level, then add operating metrics. Matt Barnes's practitioner guide to ER evaluation shows that a strong pairwise score can hide poor clusters. He recommends pairwise F1 plus at least one cluster-level metric.

Sampling matters too. Binette and coauthors found in their PatentsView study that naive benchmark estimates can mislead. They built estimators that correct for sampling bias. Label a random sample of clusters, not just the pairs your model found hard.

Graph shape is a cheap early warning. Splink computes cluster graph metrics such as size, density, and bridge edges. Oversized clusters and bridges that join two dense groups are classic signs of a false merge.

Report match quality separately from entity validity. A 98 percent match rate means little if merged entities still break business rules. Pair these numbers with provenance and lineage so each metric can be traced to specific records.

What does a realistic rollout look like?

Start with one entity type, one consumer, and conservative thresholds. Customer or supplier is usually first, because duplicate counts are visible and owners are clear. Expand to products, locations, and people only after the operating loop works.

1. Pick the entity and the first consumer, such as a revenue dashboard or a support agent.

2. Land source records unchanged and build the ID registry before any matching.

3. Run matching with a high autolink threshold and staff the review queue.

4. Write survivorship rules per attribute with source owners in the room.

5. Add post-merge validation and an unmerge path, then publish merge and split events.

6. Expose a resolve tool to analytics and agents and start tracking the metrics above.

If the platform choice is still open, the companion guide to entity resolution for enterprise data compares tools. Hub vendors in this space include Reltio, Tamr, IBM, and Informatica, which Salesforce acquired in November 2025.

Frequently asked questions

What is the difference between identity resolution and entity mastering?

Identity resolution decides which records describe the same real thing. Entity mastering decides what the company should trust once they do. It picks a value for each attribute, assigns a stable ID, routes doubtful cases to people, and keeps that entity correct as sources change. Resolution is a matching problem, while mastering is an ongoing governance job.

What is a golden record?

A golden record is the single trusted version of an entity, built from every source record that matched it. Each attribute holds the value chosen by a survivorship rule, such as the newest phone number or the legal name from the ERP. The golden record should always link back to its source records so anyone can see where each value came from.

What are survivorship rules in MDM?

Survivorship rules choose which value wins when matched sources disagree. Common strategies are source priority, most recent update, most frequent value, oldest value, and minimum or maximum value. Reltio, for example, documents more than ten strategies and defaults to the most recent update. Good programs set rules per attribute rather than one rule for the whole record.

Should I master entities in an MDM hub or a knowledge graph?

Use an MDM hub when operational systems need a clean record written back to them under strict approval workflows. Use a graph when relationships carry the evidence, as in fraud, supply chains, or AI context. Many teams run both, with the hub owning golden attributes and the graph holding links, evidence, and relationships around the same stable ID.

Why do entity IDs change and how do you stop it?

IDs change when a tool derives them from the current cluster or from load order. Senzing notes its entity IDs depend on load order, and Tamr reassigns IDs when a cluster changes. The fix is a separate ID registry that maps source keys to a permanent ID, keeps the surviving ID on merges, and turns retired IDs into aliases.

How should match confidence thresholds be set?

Use two thresholds and three bands. IBM Master Data Management calls them the autolink threshold and the clerical review threshold. Scores above the upper line merge automatically, scores between the lines go to a steward, and scores below stay separate. Start with a high autolink line, because a wrong merge usually costs more than a missed one.

Which metrics show entity resolution quality?

Track pairwise precision, recall, and F1, plus at least one cluster-level metric, as Matt Barnes recommends in his practitioner guide. Pairwise scores alone can look good while clusters are wrong. Add operating metrics too, such as steward queue age, unmerge rate, the share of entities that changed ID, and the number of oversized clusters.

How do AI agents use resolved entities?

Agents call a resolve step before they query, turning a name or email into a stable entity ID. They then fetch facts by that ID from the warehouse, graph, or documents. Reltio and Senzing both ship MCP servers for this kind of access. The key is returning the ID with its confidence and sources so the agent can cite them.

Can you unmerge a golden record?

You can if the system kept each source record and its own identifier before merging. Reltio documents that its match rules keep unique URIs per entity so merges can be undone, while its matchBeforeCreate option merges on load and cannot be unmerged. Design every pipeline so merges are reversible and downstream systems get notified of the split.

Who should own mastered entities?

The company should own them. Golden records, survivorship rules, match thresholds, and steward decisions capture years of knowledge about customers, suppliers, and products. Keeping them in open formats on infrastructure you control lets you audit them, change tools without losing history, and serve the same IDs to analytics, applications, and AI agents.