Comparisons
Master data management vs knowledge fusion
MDM governs shared business entities; knowledge fusion reconciles assertions drawn from multiple sources.
The distinction
Master data management (MDM) coordinates shared definitions and identifiers for core business entities such as customers, suppliers, and products. Its practical concern is that applications refer to the same entity and receive usable attributes under agreed ownership and stewardship. MDM can include matching, survivorship, and change control. It is especially useful when operational systems repeatedly exchange the same entities and divergent identifiers create downstream errors. Its scope is determined by the organization's master-data domain and governance needs.
Knowledge fusion addresses assertions about entities or relationships from multiple sources, including cases where the sources disagree. It asks which claims are supported, how sources differ in reliability or dependence, and what uncertainty remains. Its input may include public documents, structured feeds, and private records whose authority changes by topic and date. Fusion does not automatically replace MDM stewardship: an organization may still need a controlled master identifier and operational ownership. Conversely, a clean master identifier does not settle every contested fact attached to it.
By dimension
| Dimension | Master data management | Knowledge fusion |
|---|---|---|
| Center of gravity | Shared operational entities and stewardship. | Cross-source assertions and their support. |
| Typical input | Records from business applications. | Structured records, documents, and other evidence. |
| Identity | A stable master identity is a primary goal. | Entity alignment is necessary before claims can be compared. |
| Attribute policy | Stewardship and survivorship rules govern selected values. | Evidence and source relationships inform the status of each claim. |
| Unknowns | An attribute may be empty pending stewardship. | Absence, conflict, and unsupported claims can be distinct states. |
| Change | Operational updates propagate to consuming systems. | New evidence can revise an earlier conclusion. |
| Main risk | A chosen master value may conceal unresolved evidence. | A research conclusion may lack operational stewardship. |
Choose Master data management when
- Applications need one governed identifier for a shared business entity.
- Stewards own the domain and its update policy.
- Operational consistency is the immediate problem.
Choose Knowledge fusion when
- Facts must be reconciled across independent sources.
- Source disagreement or dependence affects confidence.
- The evidence behind each assertion must remain reviewable.
Using both
Use a governed master identity as the common subject, then attach fused, sourced assertions with their dates and unresolved conflicts.
A worked example
A fictional hospital group keeps a supplier master. Halden Laboratory Services GmbH appears there once, with one supplier number, one address and one payment term, assembled from three source systems by matching and survivorship rules. That is master data management working well: purchasing, accounts payable and receiving all point to the same supplier.
Now a compliance analyst asks whether that supplier has a manufacturing site that was cited by a regulator. The master has no field for it. The answer sits in inspection reports, a news item and a registry entry, which disagree about the site's name and the date of the finding. Reconciling them is knowledge fusion: the assertions are collected, dated, compared for independence and either resolved by a rule or left in conflict. The master identifier is the subject that those assertions attach to. It does not say what is true about the subject.
Where each one fails
Master data management fails when governance is thin. Matching rules merge two suppliers, survivorship picks the most recent value because it is most recent, and downstream systems inherit a confident mistake with no record of the alternatives. It also struggles with facts that no internal system owns, because there is no steward to settle them.
Knowledge fusion fails when the inputs are treated as independent votes. Sources that copy each other inflate agreement, and a method that estimates source reliability from agreement amplifies the copying. Work on fusion has documented the copying problem, and has shown that when claims come from automated extractors, extraction adds a source of noise that is different from the factual errors of the original sources. Without a stable subject identifier, fused assertions drift onto the wrong entity.
Questions to settle before choosing
Is the problem that systems disagree about who the entity is, or about what is true of it? The first is an identity and ownership problem. The second is an evidence problem. Who owns the answer: a data steward with authority to decide, or a reader who must weigh outside sources? Will anyone need to see the losing value later? If so, a store that keeps only the surviving value is not enough. How fast do the facts change, and who notices?
How the two meet in a review
An auditor looking at a supplier decision wants both layers. The master shows which entity the decision concerned, with its identifiers and their history. The fused assertions show what was known about that entity at the time and on what evidence. When the two are kept apart, a change of identity, such as a merge of two suppliers, can be traced to the assertions it moved, and a change of assertion can be traced without disturbing identity.
Related terms
Found an error on this page? See corrections for what counts as one, how to report it and the dated log.
Enquiry
Which do you run today: Master data management or Knowledge fusion?
Describe how your organization handles this now and one entity where it falls short. We reply with where a first record would sit alongside it and what it would need from you.
Or write to [email protected] in your own words.