MDM Cross-Source Aliases

Cross-source aliases map source-system identifiers to master entities. They are the operational crosswalk that lets FactVerse understand that several system IDs describe the same real-world object.

Example pattern:

Master entity: device
  SCADA      / tag-AHU-01
  ERP        / asset-1842
  CMMS       / work-target-77
  Inspection / checkpoint-AHU-01

Why aliases matter

Downstream workflows often join records from systems designed at different times by different teams. A sensor tag, enterprise asset ID, work-order target, and inspection checkpoint may all refer to the same object. An alias crosswalk reduces missed matches and double-counted evidence.

Resolution flow

This flow is the reason aliases should be reviewed before downstream teams depend on a fused dataset. A missing or incorrect alias can look like a data gap, duplicate asset, or confusing AI explanation.

Alias fields

Field	Meaning
Source system	System or data feed where the source ID came from.
Source ID	The raw identifier used by that source system.
Entity ID	The golden record the alias points to.
Confidence	Match confidence recorded by resolver or steward action.
Match method	Deterministic, fuzzy, or manual.
State	Active or superseded.
Period	Effective time window for temporal resolution.
Provenance	Optional structured evidence about how the alias was created.

Normalized aliases

Some domains need an additional normalized key for identity lookup. For example, one source may write a registration, serial number, or tag with punctuation while another source omits it.

In that pattern, the domain integration computes the normalized value and stores it with the source alias. Core MDM treats the normalized value as an opaque string: it matches it, but does not own the normalization rule.

Use normalized aliases carefully:

• keep the raw source ID as the primary audit trail;
• document which integration produced the normalized value;
• treat ambiguous normalized matches as steward candidates instead of confirming them automatically;
• sample the matches before using the normalized alias in production fusion.

Review aliases

1. Open Master Entities.
2. Select the entity type.
3. Open a golden record.
4. Review Cross-source aliases.
5. Check whether each active source ID belongs to the same real-world object.
6. Review superseded aliases when history or re-pointing matters.

Use source evidence when accepting an alias. Treat display-name similarity as a weak review signal.

Alias quality rules

Use these rules when reviewing a crosswalk:

Rule	Why it matters
One active mapping per source ID and period	Prevents the same source record from resolving to multiple entities.
Non-overlapping validity periods	Keeps historical facts from resolving with the wrong identity.
Stable source system names	Keeps integrations from creating duplicate namespaces.
Evidence on manual mappings	Lets reviewers explain why an alias was accepted.
Revalidation after structural changes	Ensures downstream data reflects merge, split, or re-point actions.

When source IDs can be reused, require a validity period. Without it, old work orders, sensor readings, or inspection records may resolve to the replacement equipment.

Re-point an alias

Use re-point when one source ID is mapped to the wrong active entity.

1. Open the source entity record.
2. Find the active alias.
3. Select Re-point.
4. Choose the correct target entity.
5. Confirm the action.
6. Recheck both records.

After re-pointing, the previous alias mapping is closed and a new active mapping is created.

Temporal resolution

An alias can have an effective period. This matters when a source ID is reused, reassigned, or corrected over time.

When a fact record has a timestamp, the workflow should resolve the source ID as of that timestamp. This prevents older records from being interpreted with a newer identity.

Example review cases

Case	Review action
Same asset number and same location in two systems	Confirm alias after checking entity type and source owner.
Same display name but different serial number	Reject or split; name alone is not enough.
Source ID reused after equipment replacement	Add validity periods or re-point with effective dates.
Work-order target has no asset alias	Create a steward candidate or request source correction.
Inspection checkpoint points to a retired object	Review whether historical resolution or re-point is required.

Validation checklist

• Each active source ID points to one active entity.
• Alias periods stay non-overlapping for the same source ID.
• Source systems use stable names in the crosswalk.
• Re-point decisions include source evidence.
• Downstream tasks are rerun or revalidated when identity changes affect their output.

Common issues

Symptom	Likely cause	Fix
Fusion output misses known matches	A source ID has no active alias.	Add or approve the alias before rerunning fusion.
A device or asset is double counted	Two aliases that should point to one entity point to different entities.	Merge entities or re-point aliases after review.
Historical records resolve incorrectly	Alias period is missing or was overwritten.	Review effective periods and rerun the affected workflow.
A false candidate keeps returning	The candidate was rejected without a durable negative record.	Reject through the steward queue so the pair is recorded.

Next step

Use Steward Queue for uncertain matches that require human decision.