Master Data Management
DFS Master Data Management creates governed identity records for operational data. Use it when several systems describe the same real-world asset, device, part, location, or event with different names or IDs.
Source systems remain the systems of record. MDM gives FactVerse a reviewed crosswalk: one golden record for the real-world object, a set of source aliases, and a decision history that explains how the identity was created or corrected.
MDM flow
When to use MDM
Use MDM when:
- source systems use different IDs for the same physical object;
- display names change but downstream workflows need stable identity;
- historical facts must resolve to the right entity at the time of the event;
- reviewers need to approve fuzzy or low-confidence matches;
- data quality, predictive maintenance, inspection, work-order, or AI workflows need traceable identity evidence.
Use reference data for controlled code lists such as severity levels, units, and categories. Use master entities for real-world instances that have aliases, lineage, and stewardship.
Main concepts
| Concept | Meaning | Typical examples |
|---|---|---|
| Reference data | Versioned, controlled values used to validate or normalize records. | Severity code, unit, category, status, chapter code. |
| Entity type | A class of master entities governed in the workspace. | Device, asset, part, station, vehicle, equipment. |
| Golden record | The canonical record for one real-world object. | One device record used across SCADA, ERP, inspection, and work orders. |
| Cross-source alias | A source-system ID mapped to a golden record. | SCADA/AHU-01, ERP/asset-1842, CMMS/WO-target-77. |
| Steward queue | Human review queue for uncertain identity matches. | Similar names, close IDs, reused labels, partial source records. |
| Durable negative | A rejected candidate pair recorded for future resolver runs. | Two similar source IDs that a steward confirmed are different objects. |
What users do
| Task | UI area | Result |
|---|---|---|
| Maintain controlled lists | Reference Data | Codes and labels are versioned and available to data preparation workflows. |
| Browse master records | Master Entities | Users can see canonical attributes, status, lineage, and aliases. |
| Review uncertain matches | Steward Queue | Fuzzy candidates are approved or rejected with traceable decisions. |
| Correct identity structure | Master Entities detail | Users merge duplicates, split over-clustered records, or re-point an alias. |
| Plan MDM automation | Entity Resolution Tasks | Implementation teams configure how resolver runs should produce entities, aliases, and review candidates. |
| Govern event deduplication | Fault Event Fusion | Event records reported by several systems can be grouped for review. |
Operating principles
- Keep source systems as systems of record.
- Use stable entity IDs downstream instead of display names.
- Review fuzzy matches before they change identity mappings.
- Record rejection decisions so future resolver runs can suppress known false matches.
- Treat merge, split, and re-point actions as structural data governance changes.
- Hand off MDM outputs with lineage, steward decisions, unresolved candidates, and known limitations.
Recommended first path
- Create or confirm the entity type.
- Confirm the reference data needed by the workflow.
- Load or create initial golden records.
- Add cross-source aliases for the strongest known source IDs.
- Review the steward queue.
- Correct identity structure with merge, split, or re-point only after source evidence is checked.
- Use the governed identity in DFS fusion, Inspector, AI Agent, BI, or reporting workflows.
Read next
| Page | Use |
|---|---|
| Reference Data | Manage controlled vocabularies and versioned code lists. |
| Master Entities | Browse golden records, canonical attributes, lineage, and aliases. |
| Steward Queue | Review and decide uncertain identity candidates. |
| Cross-Source Aliases | Understand and correct source ID to entity mappings. |