One customer, seven locations. Management wants to restructure territories. How long will it take?
If your architecture requires updating every location record, you’ve embedded structures in entities. If it versions a single structure, you’ve separated them correctly.
Let’s test the Three-Layer framework under increasing complexity.
Scenario 1: Basic Party-to-Location
Acme Corporation has seven ship-to locations: Warsaw plant, Krakow distribution center, Berlin office, Prague warehouse, Budapest facility, Vienna office, London headquarters.
The temptation: Store locations as properties on the customer record. Seven address fields. Or create a locations table with customer ID stamped on each row.
The problem: When Acme opens an eighth facility, what changes? When they close Prague warehouse, what updates? Every change touches either the party record or requires updating stamped location records.
Framework approach:
Acme Corporation = Master Record. Minimal intrinsic properties: legal name, tax ID, registration date, entity type. No locations embedded.
Each location = Master Record. Warsaw plant, Krakow distribution, Berlin office — each is an entity with its own minimal properties: address, delivery hours, loading dock capacity, operational status.
Party-to-location assignments = Master Data. Relationship structure connecting party to locations:
Acme Corporation (Party)├── Warsaw plant├── Krakow distribution├── Berlin office├── Prague warehouse├── Budapest facility├── Vienna office└── London headquartersThis is Master Data from Post 13. Relationship structures. Maintained by operations. Versioned when changes occur.
When Acme opens eighth facility: Create location Master Record for new facility. Add relationship in party-to-location structure. Party Master Record unchanged. Existing location Master Records unchanged. Just relationship structure updated.
When Acme closes Prague warehouse: Update location Master Record status to inactive. Remove relationship in party-to-location structure (or version it with end date). Party Master Record unchanged. Other locations unchanged.
When Acme restructures operations: Reassign locations to different operational roles. Relationship structure versions. Party and location Master Records stay unchanged unless actual properties like delivery hours change.
The separation holds. Changes affect relationship structures. Master Records stay minimal.
Scenario 2: Corporate Hierarchy
Acme Corporation isn’t standalone. It’s a subsidiary of Acme International Holdings, which is owned by Global Industrial Corp.
Three-level corporate hierarchy. How do you trace ownership chains? How do you handle reorganizations?
The temptation: Add parent company ID to party Master Record. Acme record includes “Parent: Acme International Holdings” as property.
The problem: When Global Industrial restructures — sells division, acquires competitor, merges subsidiaries — every party Master Record in the affected hierarchy requires updates. Parent IDs change. Historical reporting breaks unless you’ve time-stamped every ownership change at the party level.
Framework approach:
Each entity = Master Record. Acme Corporation, Acme International Holdings, Global Industrial Corp — all party Master Records with minimal properties. No parent IDs embedded.
Corporate hierarchy = Master Data. Relationship structure defining ownership:
Global Industrial Corp└── Acme International Holdings └── Acme Corporation └── (7 ship-to locations from Scenario 1)This is classification structure Master Data — hierarchical, but mapping relationships between entities. Versioned independently.
When Global Industrial acquires competitor: Add competitor parties as Master Records. Update corporate hierarchy structure to show new ownership relationships. Version the structure. Historical reporting uses historical hierarchy version. Current reporting uses current version. Existing party Master Records unchanged.
When Acme International Holdings is sold: Update corporate hierarchy structure. Acme International (and all subsidiaries) move to new parent. Version the structure with effective date. Historical transactions use historical hierarchy. Current transactions use current hierarchy. Party Master Records unchanged.
The pattern holds. Relationship structures handle hierarchies. Master Records stay minimal. Changes version structures, not entities.
Scenario 3: Network Membership
Acme Corporation is member of European Manufacturing Consortium. The consortium negotiated supplier agreements providing 15% volume discount with preferred vendors.
How do you know Acme gets the discount? How do you apply it to transactions? How do you handle when Acme joins or leaves networks?
The temptation: Add discount percentage to Acme’s Master Record. Or add “Network: EMC” as property with associated discount terms.
The problem: When consortium renegotiates terms — 15% becomes 18% — you update every member party record. When party leaves consortium, you remove discount from their record. Party Master Records become repositories for contractual terms that belong elsewhere.
Framework approach:
European Manufacturing Consortium = Master Record. The network itself is an entity with minimal properties: name, registration details, contract terms. The discount terms (15% volume discount) are intrinsic properties of the consortium entity.
Network membership = Master Data. Relationship structure connecting parties to networks:
European Manufacturing Consortium (Master Record: 15% discount)├── Acme Corporation (member)├── TechMfg Industries (member)├── Alpine Manufacturing (member)└── Nordic Production Group (member)Parties don’t have discounts stamped on them. Networks have discount terms in their Master Records. Membership connects parties to networks through relationship structures.
How does transaction get the discount?
Transaction ships product to Acme Corporation. Query process:
- Check party-to-network mapping (Master Data) → Acme is member of EMC
- Query EMC Master Record → discount terms = 15%
- Apply discount to transaction pricing
Query-time composition. Not pre-stamped discount on party record.
When consortium renegotiates discount: Update EMC Master Record. 15% becomes 18%. Time-stamp the change. Party Master Records unchanged. Membership structure unchanged. All members automatically get new discount for new transactions. Historical transactions used historical discount percentage from EMC Master Record effective date.
When Acme leaves consortium: Update membership structure. Remove Acme from EMC membership. Version with end date. Party Master Record unchanged. EMC Master Record unchanged. Future transactions query membership, find no match, no discount applies.
The framework holds. Network terms live in network Master Records. Membership is relationship structure. Compose at query time. No party records bloated with contractual terms.
Scenario 4: Territory Restructuring
Management restructures sales territories. Currently organized by country offices. Changing to regional model.
Current structure: Six country offices (Poland, Germany, Czech, Hungary, Austria, UK) each managing their local Acme locations.
New structure: Two regional offices (Western Europe, Eastern Europe) managing consolidated territories.
Six country offices become two regional offices. Territory restructure. This is the Post 11 problem applied to parties.
The embedded approach:
Sales office assignment is a property on location Master Records. Update every affected location:
- Warsaw Master Record: Change “Sales Office: Poland” to “Sales Office: Eastern Europe”
- Prague Master Record: Change “Sales Office: Czech” to “Sales Office: Eastern Europe”
- Berlin Master Record: Change “Sales Office: Germany” to “Sales Office: Western Europe”
- Vienna Master Record: Change “Sales Office: Austria” to “Sales Office: Western Europe”
Every location in Europe requires Master Record update. Historical reporting breaks unless you’ve time-stamped every sales office change at the location level.
This is exactly the problem Post 11 described. Territory restructure requires reprocessing Master Records.
Framework approach:
Location Master Records contain minimal properties: address, delivery hours, operational capacity. No sales office assignment embedded.
Sales territory assignment = Master Data. Classification structure organizing locations by sales responsibility:
Sales Territory Structure v1.0 (through 2025-12-31):├── Poland Sales Office│ ├── Warsaw plant│ └── Krakow distribution├── Germany Sales Office│ └── Berlin office├── Czech Sales Office│ └── Prague warehouse├── Hungary Sales Office│ └── Budapest facility├── Austria Sales Office│ └── Vienna office└── UK Sales Office └── London headquartersSales Territory Structure v2.0 (from 2026-01-01):├── Western Europe Sales Office│ ├── Berlin office│ ├── Vienna office│ └── London headquarters└── Eastern Europe Sales Office ├── Warsaw plant ├── Krakow distribution ├── Prague warehouse └── Budapest facilitySales office assignment is Master Data. It’s a classification structure organizing locations by operational responsibility. Management controls it. Changes when strategy changes.
When management restructures: Create new structure version. Effective date 2026-01-01. New regional model.
What changes: One structure.
What stays stable: All location Master Records, party Master Records, party-to-location relationships, corporate hierarchies, network memberships, transactions.
Historical reporting: “Show me sales performance by office for 2025.”
Query uses Sales Territory Structure v1.0. Warsaw rolls up to Poland office. Berlin rolls up to Germany office. Historical structure preserved.
Current reporting: “Show me sales performance by office for 2026.”
Query uses Sales Territory Structure v2.0. Warsaw rolls up to Eastern Europe office. Berlin rolls up to Western Europe office. Current structure applies.
Trending across change: “Show me Warsaw plant performance 2025 vs 2026 by responsible sales office.”
- 2025: Query with v1.0 structure → Poland office
- 2026: Query with v2.0 structure → Eastern Europe office
Both correct for their time periods. No location Master Records changed. Structure versioned.
This applies the same principle from Post 11 to a different layer. Territory restructures version Master Data structures. Master Records stay unchanged. Transactions stay unchanged. Reporting adapts using version dates.
If you embedded sales office in location Master Records: Three-month project to update every location record. Migration scripts. Data validation. Testing across all systems consuming location data. Reporting breaks if you don’t update historical assignments.
Embedded structures create the restructuring nightmare Post 11 described. Separated structures enable routine strategic changes.
What The Scenarios Reveal
Four scenarios. Increasing complexity. Multiple relationship types. Real-world changes.
The framework holds because:
Master Records stay minimal. Parties, locations, networks, corporate entities — all contain only intrinsic properties. No embedded relationships. No stamped structures.
Relationship structures handle connections. Party-to-location, corporate hierarchy, network membership, territory assignment — each is separate Master Data. Each versions independently. Each governs independently.
Query-time composition assembles views. Reporting joins transactions, Master Records, and relationship structures using dates and versions. No pre-consolidated data. No forced migration.
Changes affect structures, not entities. Open location, update structure. Restructure hierarchy, update structure. Change membership, update structure. Reassign territories, update structure. Master Records unchanged. Transactions unchanged.
What breaks if you embed:
Embed locations in party record: Opening location changes party. Closing location changes party. Every location change touches party Master Record.
Embed hierarchy in party record: Acquisition changes every subsidiary party. Restructuring changes every affected party. Corporate changes cascade through Master Records.
Embed discount in party record: Renegotiate terms, update every member party. Leave network, update party. Join network, update party. Contractual changes require mass party updates.
Embed territory in location record: Restructure territories, update every location. Strategic changes become migration projects.
Embedded structures create cascading changes. Separated structures enable isolated updates.
The pattern is consistent across all four scenarios: separate by authority, version independently, compose at query time. Master Records hold operational authority over entity properties. Master Data holds strategic authority over structures. When structures change, Master Records stay stable.
This isn’t just cleaner data models. It’s architecture that scales with complexity instead of breaking under it. Each new relationship type is a new structure. Each strategic change is a structure version. No migration. No reprocessing. No cascading updates.
The Three-Layer framework separates immutable transactions from mutable structures in Post 11. The Master Data / Master Records separation prevents embedding mutable structures in entity properties. Same principle. Different application. Consistent framework.
Understanding relationship structures as Master Data changes what’s architecturally possible. Not just theory. Strategic flexibility through proper separation.
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