Skip to content

Visual Maps 1–6

Map 1 — Shared-Context Stack

Redraw:
TRANSACTION EVENTS → involve → MASTER ENTITIES → classified/contextualized by → REFERENCE DOMAINS
METADATA → describes meaning/source/stewardship/lineage across all layers.

Interpretation: Events depend on persistent entities. Reference values give consistent classification/context. Metadata describes the data-management facts rather than becoming another business-data domain.

Answer check: Order = Transaction; Customer = Master; Order Status = Reference; steward/update schedule = Metadata.

Source: pp. 332–339.


Map 2 — Enterprise Trust Chain

Redraw:
SOURCE SYSTEMS → assess quality/semantics → STANDARDIZE/ENRICH → RESOLVE IDENTITY → TRUSTED SOURCE → SHARE TO CONSUMERS → STEWARD FEEDBACK ↺

Interpretation: Trust is produced through governed processing and feedback. It is not created by declaring a repository “golden.”

Answer check: Preparation and identity resolution are distinct. Steward feedback improves sources/rules rather than merely cleaning forever.

Source: pp. 340–347, 351–353.


Map 3 — Authority Concepts

Redraw four labels with deciding questions:

  • SYSTEM OF RECORD: Where is it created/maintained?
  • SYSTEM OF REFERENCE: Where should consumers obtain it?
  • TRUSTED SOURCE: What governed source/view should users rely on?
  • GOLDEN RECORD: What reconciled record represents this entity instance?

Interpretation: “Authoritative” can refer to different activities. The concepts can coexist in one architecture.

Answer check: Golden Record does not guarantee perfect truth.

Source: pp. 339–340, 345–351.


Map 4 — Reference Data Structure Ladder

Redraw:
LIST → CROSS-REFERENCE → TAXONOMY → ONTOLOGY
code/description → translate representations → hierarchy → richer semantic relationships

Interpretation: The key is the relationship required, not merely “complexity.”

Example: status list → ISO code crosswalk → product hierarchy → formal domain relationship model.

Source: pp. 334–338.


Map 5 — MDM Processing Spine

Redraw:
MODEL → ACQUIRE → VALIDATE / STANDARDIZE / ENRICH → ENTITY RESOLUTION + ID MANAGEMENT → SHARE + STEWARD

Interpretation: Define common semantics and prepare evidence before identity decisions.

Answer check: Matching before adequate modeling/source assessment/standardization is a common sequencing error.

Source: pp. 341–347.


Map 6 — Matching Decision

Redraw:
CANDIDATE PAIR → similarity evidence → SAME ENTITY?

If system says SAME but truth is DIFFERENT → FALSE POSITIVE.
If system says DIFFERENT but truth is SAME → FALSE NEGATIVE.

Add: MATCH HISTORY + REVERSIBILITY ↺

Interpretation: Matching is a governed decision under uncertainty. Error costs drive thresholds and stewardship.

Answer check: false positive over-combines; false negative under-matches.

Source: pp. 343–346.

← Atlas · Maps 7–12 →