MDM Fault Event Fusion

Fault event fusion helps teams review whether several source records describe the same real-world event. It is useful when systems report similar faults with different descriptions, timestamps, categories, or IDs.

This page describes the governance pattern. The exact scoring configuration depends on the implementation and source systems.

Current steward surface

The current fault-event review surface is separate from master-entity review:

Action	Endpoint family
List candidates	/api/v1/dfslite/fault-fusion/candidates
Approve duplicate group	/api/v1/dfslite/fault-fusion/candidates/{id}/approve
Reject duplicate group	/api/v1/dfslite/fault-fusion/candidates/{id}/reject

Reads use DFS read permission; approve and reject actions write a steward decision. Use MDM API Reference when planning API-level integration.

Published ruleset view

The fault-fusion entry in DFS Pro reflects the currently published fusion ruleset for the deployment. Use it to inspect the field extraction, matching, survivorship, confidence, and AI-assist settings that the fusion service uses for the run. Empty ruleset blocks mean that part of the workflow has not been configured yet.

This keeps review work aligned with live fusion behavior. Base training and handoff notes on the published ruleset used by the operating task.

When to use fault event fusion

Use it when:

• several systems report the same fault or incident;
• natural keys miss duplicates because descriptions or timestamps differ;
• reports double-count events;
• maintenance, inspection, or reliability workflows need a reviewed event identity;
• AI Agent answers need source evidence from more than one system.

How the review works

Candidate signals

Signal	How it helps
Resolved entity ID	Confirms records refer to the same object.
Time window	Finds records close enough to be the same event.
Description similarity	Finds wording differences for the same condition.
Category or severity	Helps compare source classification.
Work-order or inspection link	Provides operational evidence for review.

Combine several signals before confirming a group. Similar descriptions on different assets should be treated as separate events.

Conflict comparison scope

Conflict comparison should focus on fields that change the business meaning of an event. Good examples include governed identity, time bucket, status, severity, category, asset class, batch context, equipment state, and maintained object. Free-text messages and source-specific codes are often useful evidence, but they can create noisy conflict counts when different systems describe the same event in their own wording.

Before moving a task into regular operation, sample the fields that drive conflict counts. Keep evidence-rich fields in the source evidence and reviewer view, and reserve the conflict flag for fields that should trigger human attention.

Event grouping states

Use clear states so downstream users know whether a report is using raw events or reviewed event groups.

State	Meaning	Downstream use
Raw	Source event has not been compared.	Use for source audit and ingestion troubleshooting.
Candidate	Resolver found a possible duplicate group.	Use for steward review only.
Confirmed group	Steward confirmed that records describe the same event.	Use for reliability analysis, event counts, AI Agent evidence, and reporting.
Rejected pair	Steward rejected the candidate relationship.	Reuse to prevent the same false duplicate from returning.
Split required	A candidate group contains more than one real event.	Split before publishing reviewed event output.

Review candidates

For each candidate group:

1. Check the resolved entity or asset identity.
2. Compare source timestamps.
3. Compare fault description, category, and severity.
4. Check work-order or inspection evidence when available.
5. Confirm whether the records describe the same event.
6. Reject pairs or groups that are only superficially similar.

When reviewing a group, compare both the event evidence and the operational follow-up. A fault record and a work order can describe the same incident even when the text fields differ. Two alarms with the same wording can still be separate incidents when they occur on different assets or during different operating windows.

Reviewed output fields

A reviewed event dataset should expose enough context for downstream teams:

Field	Purpose
Reviewed event ID	Stable identifier for the confirmed event group.
Master entity ID	Connects the event to the governed asset or equipment identity.
Source event IDs	Preserves traceability back to raw source systems.
Primary timestamp	Defines the event time used for reporting.
Time window	Shows the source record range included in the group.
Review status	Separates raw, candidate, confirmed, rejected, and split-required records.
Decision note	Explains manual decisions that may affect reliability reports or AI Agent answers.

Publish raw source IDs alongside reviewed IDs. This lets auditors trace an answer or report back to original system records.

Output use

Confirmed event grouping can support:

• reliability analysis;
• predictive maintenance evidence;
• incident review;
• inspection and work-order follow-up;
• BI reporting;
• AI Agent explanations that cite source evidence.

Implementation scenario

For a facility or manufacturing environment, a practical setup often looks like this:

1. DFS Lite imports alarms, maintenance requests, inspection findings, and work-order records.
2. MDM resolves asset or equipment identity before event grouping starts.
3. The resolver proposes candidate event groups based on entity ID, time window, text similarity, category, and linked work evidence.
4. Stewards confirm or reject groups in the queue.
5. DFS Pro publishes a reviewed event dataset with raw source IDs and reviewed event IDs.
6. Inspector, reliability reporting, or AI Agent workflows use the reviewed event identity to avoid duplicate incident counts and to cite source evidence.

This scenario works best when the source systems already have consistent asset identity, event timestamps, and operational categories. When those fields are weak, improve mappings before expanding the resolver to more sources.

Validation checklist

• Asset or equipment identity is resolved before event grouping is trusted.
• Time-window rules match the operational domain.
• Similarity scores are treated as review signals.
• Rejected pairs are recorded for future resolver runs.
• Downstream reports state whether they use raw events or reviewed event groups.
• Reviewed event output includes raw source IDs for audit.
• Confirmed groups are sampled against work-order or inspection evidence.
• Split-required groups are resolved before production reporting uses them.

Common issues

Symptom	Likely cause	Fix
Duplicate events remain	Time window too narrow or asset identity unresolved.	Review entity aliases and scoring configuration.
Different events are grouped	Time window too broad or description match too permissive.	Tighten rules and reject false groups.
Review queue is too large	Source quality or match keys are weak.	Improve source mappings and add stronger identity signals.
AI answers cite confusing evidence	Raw and reviewed event sets are mixed.	Hand off the reviewed dataset or grouping status clearly.

Next step

Use Industry Recipes for examples of how MDM supports operational workflows.