MDM Merge, Split, and Re-Point

Merge, split, and re-point actions change the structure of MDM identity. Use them only after source evidence has been reviewed.

These actions affect downstream fusion, AI Agent evidence, Inspector records, BI, and reports that rely on stable identity.

Choose the right action

Action	Use when	Result
Merge	Two golden records represent the same real-world object.	One record becomes the survivor; aliases move to the survivor.
Split	One golden record contains aliases from more than one real-world object.	Selected aliases move to a new golden record.
Re-point	One alias points to the wrong golden record.	The alias is closed on the old record and opened on the correct record.

Change-control flow

Use this flow for production identity changes. It keeps the identity action, downstream refresh, and audit note connected.

Before changing identity

Confirm:

• source-system evidence;
• entity type;
• active aliases and superseded aliases;
• downstream datasets and workflows that use the entity;
• whether historical records need temporal handling;
• who approved the structural decision.

Impact assessment

Before applying the action, list the affected surfaces:

Surface	What to check
DFS Pro datasets	Which fusion tasks join on this entity ID or alias?
Inspector	Are inspection workflows, checkpoints, or work records linked to the entity?
AI Agent	Will answers or evidence retrieval change after the identity update?
BI and reports	Which charts, counts, or filters aggregate by this entity?
External integrations	Are downstream systems storing the master entity ID or source alias?
Historical records	Do old facts need to resolve using an earlier alias period?

If the affected surface is unclear, pause the structural action and resolve the dependency first. Fast identity changes are rarely worth a silent reporting change.

Merge records

Use merge only when two golden records are the same real-world object.

1. Open Master Entities.
2. Select the duplicate record that will become the merged record.
3. Choose Merge into.
4. Select the surviving entity.
5. Confirm the merge.
6. Reopen the survivor and check aliases, canonical attributes, and lineage.

After a merge, the merged entity remains as a tombstone. Add new aliases to the survivor.

Split records

Use split when one golden record is over-clustered.

1. Open the affected golden record.
2. Review active aliases.
3. Select the aliases that belong to another real-world object.
4. Choose Split.
5. Provide canonical attributes for the new entity when available.
6. Confirm the split.
7. Review both the original and new records.

A split must leave at least one active alias on the original record.

After a split, check whether each resulting record has enough canonical attributes for users to recognize it. A split that creates an unnamed or unsupported record may need source correction before downstream use.

Re-point an alias

Use re-point for a single incorrect source mapping.

1. Open the golden record that currently owns the alias.
2. Select Re-point on the alias row.
3. Choose the correct target entity.
4. Confirm the action.
5. Check that the target now shows the alias.

Downstream validation

After any structural action:

• rerun or revalidate affected fusion tasks;
• check dashboards or reports that aggregate by the entity;
• inform owners of AI Agent workflows using the entity as evidence;
• record unresolved historical questions;
• keep the steward decision in project handoff notes.

Post-change evidence

Attach a short note after every structural action:

Action: re-point
Reason: work-order target mapped to retired equipment
Source evidence: CMMS asset number and inspection checkpoint history
Old entity: equipment-0172
New entity: equipment-0441
Effective period: from 2026-04-01
Downstream refresh: work-order fusion rerun; AI Agent evidence cache refreshed
Reviewer: facility data steward

Keep the note short, specific, and auditable. It should explain the decision, the evidence used, and the downstream refresh status.

Common mistakes

Mistake	Impact	Better approach
Merge based only on similar names	Different objects may be collapsed.	Check source IDs, location, serial, class, and source owner evidence.
Split without checking downstream output	Reports may change unexpectedly.	Identify affected datasets before the action.
Re-point the only alias away from a record without review	The original record may become orphaned.	Confirm whether the record should be merged, retired, or left with another alias.
Ignore historical time periods	Old facts may resolve to the wrong identity.	Check effective periods and rerun affected workflows.

Next step

Use Entity Resolution Tasks to understand how resolver runs can create entities, aliases, and steward candidates.