MDM Industry Recipes

These recipes show how DFS MDM supports operational workflows. Treat them as implementation patterns that should be adapted to the source systems, governance model, and deployment scope of each project.

Recipe structure

Use the same structure when turning a pattern into a customer implementation:

Each recipe should identify the object being governed, the source systems involved, the steward owner, and the downstream workflow that will consume the governed output.

Facility and utility operations

Use MDM to connect physical equipment with operational systems.

Typical aliases:

Source	Example identity
Building or facility model	Equipment or asset ID.
SCADA or BMS	Point name, tag, or controller path.
ERP or EAM	Asset number.
Work-order system	Maintainable object or work target.
Inspection system	Checkpoint or inspection route target.

Workflow:

1. Create entity types for equipment or devices.
2. Load known assets as master entities.
3. Add aliases from SCADA, ERP, work-order, and inspection systems.
4. Review uncertain aliases in the steward queue.
5. Use the governed crosswalk in Inspector, maintenance planning, energy analysis, or AI Agent workflows.

Validation:

• Each maintainable object has at least one enterprise asset alias.
• Sensor tags resolve to the right physical equipment.
• Work orders and inspection records can be joined to the same entity.
• Orphan tags and orphan work targets are tracked.

Implementation notes:

• Use equipment class and location reference data before reviewing aliases.
• Keep BMS or SCADA tag identity separate from the maintainable equipment identity when one equipment item has many points.
• Review orphan tags with the facility owner instead of treating them as missing data only.
• Record which downstream workflow uses the entity: inspection route, maintenance plan, energy analysis, or AI Agent evidence.

Predictive maintenance

Use MDM to align signals, maintenance history, inspection findings, and asset metadata.

Workflow:

1. Confirm the target entity type, such as equipment, device, or component.
2. Map sensor history to stable aliases.
3. Map work orders and inspection findings to the same entity IDs.
4. Use reference data for status, severity, failure category, and units.
5. Build a governed dataset for feature preparation and model evidence.
6. Review unresolved identities before model output is used operationally.

Good handoff output:

• entity type;
• signal sources and sampling range;
• maintenance and inspection source coverage;
• unresolved alias count;
• feature dataset version;
• known gaps that may bias model output.

Implementation notes:

• Resolve sensor, work-order, inspection, and asset metadata to the same master entity before feature preparation.
• Keep raw source IDs in the feature dataset lineage so model evidence can be traced back.
• Track unresolved identities separately from normal missing sensor values.
• Do not use prediction output operationally until identity exceptions that affect target assets are reviewed.

Reliability and event review

Use MDM when records from multiple operational systems describe assets, parts, events, or reliability observations with different identifiers.

Workflow:

1. Create entity types for the objects that need stable identity.
2. Maintain reference data for codes and categories.
3. Resolve source IDs to master entities.
4. Use event fusion to propose duplicate event groups.
5. Review candidates and rejected pairs.
6. Publish a governed output for analysis or reporting.

Validation:

• the same real-world object resolves consistently across source systems;
• event grouping combines identity, time, text, and operational evidence;
• historical records use the correct identity period;
• reports distinguish raw source counts from reviewed event counts.

Implementation notes:

• Define whether the primary object is an asset, component, part, or event group before designing aliases.
• Use reference data for failure category, severity, status, and inspection result codes.
• Preserve rejected event pairs so false duplicate groups do not return every run.
• Publish both raw event counts and reviewed event counts when the audience needs auditability.

AI Agent evidence

Use MDM when AI Agent workflows must explain operational status with source evidence.

Workflow:

1. Define which object the Agent is allowed to reason about.
2. Resolve source records to that object through MDM aliases.
3. Provide reviewed datasets or API results with entity ID, source IDs, timestamps, and lineage.
4. Include unresolved identity cases in the Agent handoff.
5. Validate the Agent output against the source evidence.

Give the Agent reviewed identity evidence from MDM. Identity decisions belong in MDM and the steward workflow.

Implementation notes:

• Provide entity ID, source IDs, source timestamps, and lineage together.
• Include unresolved identity cases in retrieval filters or handoff notes so the Agent does not overstate coverage.
• Refresh Agent-facing datasets after merge, split, or re-point actions.
• Use MDM status and steward decisions as evidence metadata, not as generated claims.

Next step

Use API Reference when planning integration or automated validation around MDM.