Skip to content

Master Record Consolidation

Governed workflow — instantiates Equivalence Class Consolidation

Assembles a single governed master record for a class from its duplicates, choosing surviving field values while preserving aliases, lineage, and an accountable owner.

Master Record Consolidation is what happens after a set of records has been judged the same: it builds the one authoritative record the class will present to the world, and stands up the governance that keeps that record trustworthy. Its distinguishing concern is not finding duplicates — it consumes that judgment — but stewardship of the survivor. It resolves the conflicting field values across the sources into one "golden" record, keeps every merged source and its aliases attached so nothing is lost, writes down the lineage and the reason for the merge, and hands the result to a named owner accountable for it. The move that makes it this mechanism is that it treats the master record as a governed, reversible, owned artifact — not a one-time delete of the losers.

Example

Two manufacturers merge, and both ERPs carry the supplier "Acme Industrial" — different vendor IDs, slightly different addresses, different payment terms, and two tax IDs, one of them stale. Left unconsolidated, purchase orders, payments, and spend analytics scatter across both records and the company can't even see how much it buys from Acme. Master Record Consolidation assembles one golden supplier record: survivorship rules pick the most-recently-verified address, keep the valid tax ID, and reconcile payment terms to the surviving contract. Both legacy vendor IDs are retained as aliases so open POs still resolve; the merge lineage records which sources combined, when, and on whose approval; and a procurement data steward is named as the class owner responsible for keeping it correct. Now every downstream system keys on one Acme — and if the merge later proves wrong, the preserved lineage lets it be pulled apart.

How it works

Its distinguishing traits are field-level survivorship and governed reversibility:

  • It resolves conflicts by survivorship rules — per field, choose the value by recency, source trust, completeness, or manual override — to assemble the master record, rather than simply picking one source wholesale.
  • It preserves rather than deletes: merged sources, their identifiers, and their aliases stay attached, and the merge lineage is written so the consolidation can be traced and unwound.
  • It assigns accountability and an audit trail — who approved the merge, under which criterion, and who now owns the record — so the golden record has a steward and a downstream-legible justification.

Tuning parameters

  • Survivorship rule set — recency-wins, most-trusted-source-wins, most-complete-wins, or human-curated per field. Automatic rules scale but can enshrine a fresh-but-wrong value; curation is accurate but slow.
  • Lineage depth — how much of each source's history and prior values is retained. Deep lineage is what makes an unmerge possible; shallow lineage saves storage but makes reversal guesswork.
  • Unmerge support — whether the process is designed to split a master back into its sources on demand, or treats merges as one-way.
  • Ownership model — a single steward per record versus a domain-level owner. Concentrated ownership is clear but a bottleneck; distributed ownership scales but blurs accountability.
  • Reprocessing trigger — whether new evidence re-opens survivorship decisions automatically or only on request.

When it helps, and when it misleads

Its strength is a single trustworthy record that downstream systems can rely on — correct spend rollups, consistent contact, no more reconciling three versions — combined with the safety net of preserved lineage that keeps the merge reversible when it turns out wrong.

Its danger is blast radius: once a wrong merge is declared the golden record, its error propagates as authoritative to every system that trusts it, and the tidy single record makes the mistake look confident. Survivorship rules can crown the wrong field value — the freshest entry is not always the correct one — and if lineage was skimped, there is no way back. The misuse to watch is declaring a master record to settle a data-ownership turf war rather than because the equivalence actually holds, or letting the record drift once the owner's attention moves on. The discipline is to preserve full lineage so any merge can be reversed, make survivorship rules explicit and owned rather than implicit, keep an accountable steward, and re-open the consolidation when new evidence arrives.[1]

How it implements the components

  • canonical_representative — the golden master record is the class's single authoritative representative; assembling it via survivorship is the workflow's output.
  • merge_history — it preserves the lineage of which sources merged, when, and under what criterion, so the merge can be traced and unwound.
  • consolidation_audit_record — it records the grouping rationale, the criterion applied, and who approved it, for accountability and downstream interpretation.
  • class_owner — it assigns a named steward accountable for the master record's ongoing correctness.

It does not find the duplicates or infer the matches — those come from the Deduplication Workflow and Identity Resolution Model it consumes — nor does it map codes across external schemes (Crosswalk Table).

References

[1] In master data management the consolidated authoritative record is the golden record, and the per-field rules that decide which source value survives a merge are survivorship rules — the recognized names for the machinery this mechanism governs, and the reason lineage is retained for reversibility. ↩