Last post established the distinction: Master Data = structures, Master Records = entities, Transactions = events. Let’s now deep dive into Master Records and how we could architect them differently.
What Master Records Are
Master Records are specific entities. Individual things that exist in your business.
Customers:
- Customer #12345 (Acme Corporation)
- Customer #67890 (TechCo Inc)
Products:
- Product SKU-789 (Business Laptop Model X)
- Product SKU-456 (Enterprise Server Model Y)
Locations:
- Ship-to Location SL-10001 (Acme Warsaw Plant)
- Ship-to Location SL-10002 (Acme Krakow Plant)
Employees:
- Employee S-456 (Jane Smith, salesperson)
- Employee S-789 (John Chen, account manager)
Each one is a thing. An entity. A specific instance. Not a category. Not a structure. An actual entity with properties and a state. This matters because entities have different architectural requirements than structures.
Master Records Have Properties
Customer #12345 isn’t just an ID. It’s an entity with characteristics:
Customer #12345: Acme Corporation- Legal Name: Acme Corporation Ltd- Tax ID: UK123456789- Registration Date: 2010-03-15- Primary Address: London, UK- Status: Active (i.e. its state)- Contact Email: info@acme.comThese are properties of THIS customer. They describe THIS entity. Not customers in general. This one.
Properties change over time. Address changes when they relocate. Status changes when the relationship changes. That’s why Master Records need time-stamping:
Customer #12345 properties:2020-01-01 to 2023-12-31:- Address: Manchester, UK- Status: Active2024-01-01 onwards:- Address: London, UK- Status: ActiveProperties evolve. Time stamps preserve what was true when.
This is different from Master Data versioning. Master Records track property changes. Master Data tracks structural reorganizations.
Master Records You Create
Not all Master Records are discovered in the world. Some you define and create yourself.
Products you specified:
- SKU-789: 16GB RAM, 512GB SSD, Intel i7, 14″ screen
- SKU-456: 64GB RAM, 2TB SSD, Dual Xeon, Rack-mount
Your Locations you designated (or the one you outsourced production to)
- SL-10001: Berlin plant, delivery hours 8am-6pm, loading dock capacity 5 trucks
- SL-10002: Munich plant, 24-hour operations, rail access
You decided these entities exist. You defined their properties. You control when they change.
You create them. You operate with them. You govern their properties.
But you don’t organize them – that’s what Master Data structures do.
The Separation That Changes Everything
Here’s what the Master Data / Master Records distinction actually means in practice:
Master Records = Entities:
- Customer #12345
- Properties: Name, address, tax ID
- Changes: When entity facts change (moved, renamed)
- Governance: Operational (sales ops, customer service)
- Authority pattern: Operational authority over properties
Master Data = Structures organizing entities:
- Territory hierarchy (Strategic Accounts > North Region > Enterprise Sales)
- Classification rules (Revenue > $1M = Strategic Account)
- Changes: When strategy changes (territory reorganization)
- Governance: Strategic (management, architecture)
- Authority pattern: Strategic authority over organization
Customer #12345 is a Master Record. The territory structure that classifies Customer #12345 as “Strategic Account in North Region” is Master Data.
The entity exists independently of how you classify it.
That independence is architectural. You can restructure territories without touching customer records. You can change classification rules without reprocessing entities.
The structures are mutable. The entity facts are what they are.
Why Traditional MDM Fails Here
Traditional MDM conflates these. “Master Data Management” becomes “manage all the important data” without separating entities from their organizing structures.
Result: Territory restructuring requires reprocessing customer records. Taxonomy changes require updating product definitions. Org chart changes require modifying employee records.
Three months to change a classification structure.
Not because the decision is hard. Because you embedded mutable structures (Master Data) in stable entities (Master Records).
The three-layer architecture prevents this:
Transactions reference Master Records by ID. Just the ID.
Master Records contain entity properties. Time-stamped so you know what was true when.
Master Data contains classification structures. Versioned independently so management can restructure without touching operational data.
Reporting joins them at query time. Transaction date + Master Record effective date + Master Data version = correct classification for that point in time.
No reprocessing. No propagation. Query-time assembly.
Master Record Principles
Understanding Master Records as entities leads to specific architectural principles.
These seem to hold across insurance, manufacturing, housing – 12+ years building business architecture:
Master Record Principles
Understanding Master Records as entities leads to specific architectural principles.
These seem to hold across insurance, manufacturing, housing – 12+ years building business architecture:
Principle 1: Minimal necessary properties
Store intrinsic entity facts – not derived classifications, not calculated values. Just what’s true about this entity.
Customer #12345 has legal name (Acme Corporation Ltd) and tax ID (UK123456789), but territory assignment belongs in Master Data structures, and customer lifetime value belongs in analytics.
Why minimal? Because every property in a Master Record requires operational governance. More properties means more governance overhead. Master Data handles classification. Analytics handles calculation. Master Records handle entity facts.
Principle 2: Time-stamped changes
Properties change over time, so preserve history with effective dates. No “current state only” architecture. You’ll need historical reporting, audit trails, answers to “what did we know about this customer on June 15?”
Time-stamp from the start because retrofitting temporal data is painful. Adding effective dates after the fact breaks everything.
Principle 3: Single source per property type
Don’t duplicate entity facts across systems. Pick authoritative source for each property type. Customer legal name comes from CRM. Customer shipping address comes from Order Management.
The Master Record exists across systems, but each property has single authority. This is different from “golden record” approaches that try to create one master copy. The entity exists in multiple systems. Who has authority over specific properties is what matters.
Principle 4: Stable identifiers
IDs don’t change, ever. Customer #12345 stays #12345 forever, even if company name changes, even if acquired, even if relocated.
Everything else in the Master Record can change. The ID never changes.
Why? Because Transactions reference Master Records by ID. If IDs change, you break transaction history. Stable identifiers enable everything else to be mutable.
Customer #12345 properties (2025-10-28)
Customer #12345 properties:2020-01-01 to 2023-12-31:Address: Manchester, UKStatus: Inactive2024-01-01 onwards:Address: London, UKStatus: ActiveLet’s deep dive into Cross-System Master Records
In real enterprises, Master Records live in multiple systems.
CRM has customers. ERP has customers. Billing has customers.
Not duplicates. Not golden records. Different systems, different purposes, same real-world entity.
Understanding Master Records as entities changes how you handle this.
You don’t try to consolidate. You don’t create golden records. You map across systems.
Cross-system mapping structure (Master Data):
Entity Mapping:Real-world: Acme Corporation├── CRM: CRM-12345├── ERP: ERP-98765└── Billing: BILL-45678The Master Records exist in their systems, with the properties each system needs. The mapping structure (Master Data) connects them.
This is why the Master Data / Master Records distinction matters architecturally.
Master Records = entities in operational systems, governed operationally. Master Data = structures that organize/map entities, governed strategically.
No golden record needed. Just well-governed mappings.
The Minimal Principle Revisited
Master Records should contain minimum necessary properties.
Not because minimalism is virtuous. Because governance overhead scales with property count.
You include identity (ID, legal name), intrinsic facts (tax ID, registration date, serial number), contact and admin details (address, email, phone), and status (active, inactive, suspended). You don’t include derived classifications like territory, segment, revenue category etc – those belong in Master Data. You don’t include structural relationships like team membership, hierarchies, or networks – those belong in Master Data. You don’t include calculated values like credit score or lifetime value – those belong in the analytics layer.
Each property you add requires operational governance (who updates, when, how), creates dependencies (who consumes this property), and adds to change management overhead (what happens when it changes). Derive classifications from properties plus structures at reporting time. Keep Master Records minimal. Push complexity to Master Data and reporting.
Implementation Sequence
The Master Data / Master Records distinction seem to change the implementation sequence.
You can’t version Master Data structures until you stabilize Master Records.
Start with Master Records. Identify your core entities – customers, products, employees, locations. Define intrinsic properties, asking what describes THIS entity, not how you classify it. Implement time-stamping to preserve property history.
Then analyse what should be Master Data. Pull out structures like territories, taxonomies, and org charts. Version these structures separately from entities. Create classification rules. Implement strategic governance where management controls structures.
Then remove the embedded structures from the Master Records – no territory assignments, no hierarchies. Establish operational governance around who updates what and when.
Lastly, join everything at reporting time where properties plus structures equals classifications.
Master Records are the foundation. Master Data structures organize them. Build a stable foundation first.
To my understanding, this is the opposite of traditional MDM, which tries to build golden records (entities plus classifications) first. Understanding the distinction changes the implementation sequence.
What This Changes
Get Master Records right – stable entities with time-stamped properties – and Master Data becomes manageable.
Get Master Records wrong – embedded structures, missing time-stamps, bloated properties – and Master Data governance becomes impossible.
The distinction isn’t semantic. It’s architectural.
Master Records = Stable entities with time-stamped properties
- Operational governance
- Property-level authority
- Changes when entity facts change
Master Data = Mutable structures organizing entities
- Strategic governance
- Structure-level authority
- Changes when strategy changes
Transactions = Minimal references to Master Records
- Just IDs
- Immutable events
- No embedded properties
Reporting = Query-time assembly
- Join Transaction + Master Record + Master Data
- Use effective dates and version numbers
- Reconstruct classification at any point in time
Clean separation. Clear governance. Operational stability. Strategic flexibility.
That’s what the Authority rules give you with regards to Master Records as entities.
Not just “entities to manage.” Foundation for architecture that scales.
This post is part of the Systems Thinking Series and how the 5 authority types impact system design. Read the full series at authorityrule.com/
Leave a Reply