Data Authority Rule

Tag: Master Data Management

  • Just Because You Master It Doesn’t mean it is Master Data.

    For years, something bothered me about data discussions.

    People would say “currency codes are our master data” and I’d feel this cognitive dissonance. We maintain them. We distribute them. Other systems depend on us for them. By every traditional definition, we “master” this data.

    But something felt off. I couldn’t put my finger on it or articulate what was jarring to me.

    Then I discovered the Authority Rule—that simple question that cuts through everything: “Who has the authority to redefine what this means?”

    And suddenly, the fog lifted. What had been jarring me for years became crystal clear.

    The Moment It Clicked

    Currency codes. EUR means Euro. USD means United States Dollar. GBP means British Pound.

    Ask yourself: Can your organization decide EUR means something else? Can you give USD three decimal places instead of two? Can you invent a new currency code and expect the world to accept it?

    No.

    You can’t. Because you don’t have the authority. ISO does.

    In fact, ISO masters it for the world, holding the final definition, making it reference data for everyone else. When one entity has authority for everyone, it automatically becomes reference data for all consumers.

    This isn’t about technical capability. You could absolutely change CHF to mean “Chilean Franc” in your database instead of Swiss Frank – the definition the rest of the world uses. You have the technical power. But you don’t have the authority. And that difference, between capability and authority, is everything.

    The Pattern I Keep Seeing

    Once this clicked, I started seeing it everywhere:

    Currency codes: You maintain them perfectly. You might even add business rules—which currencies you trade, your risk limits, your preferred banks. But the codes themselves? Not yours. ISO 4217 owns those.

    Exchange rates: Here’s where it gets interesting. The rate itself? That’s your master data—you choose your source, your timing, your calculation method. But the currency codes those rates reference? Still ISO’s.

    Country codes: Your systems depend on them. Every address, every tax calculation, every shipping route. But can you decide that GB means Germany instead of Great Britain? No. ISO 3166 has that authority.

    Sales territories: Now we’re in your domain. How you divide regions, which countries belong to EMEA vs APAC, your sales areas—that’s your master data. You define it, others in your organization accept it.

    SWIFT codes: Financial institutions treat these like crown jewels. SWIFT defines them. You’re just maintaining a subscription.

    Tax codes: Governments define them. You configure how to handle them. The codes are reference data. Your configuration is master data. Two different things, accidentally welded together.

    The pattern repeats: Just because you “master it”—maintain it, distribute it, depend on it—doesn’t mean it’s Master Data. You’re mastering the maintenance, not the meaning.

    Why This Distinction Matters

    This isn’t semantic philosophy. This confusion creates real problems:

    The Governance Theater

    When you treat reference data like master data, you create elaborate governance for things you don’t control. Approval workflows for copying ISO updates. Committees to discuss SWIFT code changes. Review boards for government tax codes.

    It’s governance theater. You’re governing your ability to copy someone else’s homework.

    Meanwhile, your actual master data—the business decisions that differentiate you—often has no or limited governance at all. Your credit limits, your risk ratings, your pricing strategies, your customer segments. The data you actually own and control.

    The Integration Maze

    When two systems exchange currency codes, whose version is “right”? If both think they’re the master, you get conflicts. Mapping tables. Transformation rules. Endless reconciliation.

    But neither of you owns currency codes. You’re both subscribing to the same external truth. The conflict is imaginary—like two people arguing about the “correct” spelling of a word when the dictionary is right there.

    The Update Paralysis

    When ISO updates a standard, organizations freeze. “We need to assess the impact.” “We need approval to update.” “We need to coordinate across systems.”

    No, you don’t. It’s reference data. When the dictionary adds a new word, you don’t convene a committee. You just use the new edition.

    But because you’ve confused maintenance with ownership, every update becomes a project.

    The Hybrid Problem

    Here’s where it gets genuinely complex. Most datasets aren’t pure. They’re hybrid.

    Take your currency table:

    • Currency code (EUR): Reference data (ISO’s authority)
    • Currency name (Euro): Reference data (ISO’s authority)
    • Decimal places (2): Reference data (ISO’s authority)
    • Exchange rate (1.18): Master data (your chosen source/timing)
    • We trade this (Yes): Master data (your authority)
    • Risk rating (Medium): Master data (your authority)
    • Preferred dealers (Bank1, Bank2): Master data (your choice of who)
    • Dealer legal names/post codes: Reference data (outside your authority)

    You’ve mixed external truth with internal decisions. Reference data with master data. And because you can’t see the boundary, you treat it all the same.

    When ISO updates, you’re afraid to accept the changes. You might “lose” your enrichments. You’ve welded together things that should be separate.

    The Clear Path Forward

    The Authority Rule makes the path clear:

    For pure reference data:

    • Subscribe to the authoritative source
    • Update automatically when they update
    • Don’t govern it—you don’t own it
    • Cache it locally for performance
    • Never modify the standard values

    For pure master data:

    • Govern it carefully—this is yours
    • Track changes and audit trails
    • Control the lifecycle
    • Define the business rules
    • Own the decisions

    For hybrid datasets:

    • Separate the layers
    • Link, don’t embed
    • Update reference data independently
    • Preserve master data separately
    • Document the boundary clearly

    My Discovery Journey

    This framework didn’t come from reading data management textbooks. It came from pattern recognition—the same approach I use to understand complex systems.

    I kept seeing people struggle with the same classification problems. Master or reference? Who owns what? Where does governance apply? The existing definitions weren’t helping. They focused on technical characteristics—volatility, cardinality, lifecycle. But these weren’t the real differentiators.

    The real differentiator was authority. Who gets to say what something means?

    Once I found that question, everything else fell into place. Currency codes—reference. Your trading decisions—master. Tax codes—reference. Your tax configuration—master. The pattern holds everywhere.

    The Liberation

    Understanding this distinction is liberating.

    You stop wasting time governing things you don’t own. You stop creating false conflicts in integrations. You stop treating external standards like internal decisions.

    You can maintain reference data excellently—keeping it current, available, well-distributed—without confusing it with ownership. In fact, you’ll maintain it better once you stop pretending it’s yours.

    Your actual master data—the decisions only you can make, the data that differentiates your business—they now get the attention they deserve.

    The Simple Test

    When you’re unsure about any piece of data, ask the Authority Rule question:

    “Can we redefine what this means and expect others to accept our definition?”

    • Currency code EUR: Can you redefine it? No. Reference data.
    • Exchange rate for EUR: Can you choose your source? Yes. Master data.
    • Country code USA: Can you change it? No. Reference data.
    • Sales territory “Americas”: Can you redefine it? Yes. Master data.

    If yes, it’s master data. Govern it. Own it. Control it.

    If no, it’s reference data. Subscribe to it. Synchronize it. Use it.

    Just because you “master it” doesn’t mean it’s Master Data. Just because you maintain it excellently doesn’t mean you own it. The source of truth doesn’t move with the copy. And recognizing this difference isn’t just precision—it’s the key to effective data governance.

    Next in this series: “Why Exchange Rates Are Master Data (Yes, Really)” – why external sources don’t determine data classification, and how the USC taught me about authority twenty years before I had the words for it.

  • When Dropdowns Lie: Why Data Format Doesn’t Determine Authority

    I’ve been thinking about why data classification has gotten more confusing over my career, not clearer.

    Early on, working with SAP, there was some structure. “System provided values” versus values you configured during implementation. Country codes came from SAP. Sales areas came from you.

    But we never articulated why that distinction mattered.

    Fast forward to today, and I sit in meetings where experienced data professionals argue for 30 minutes before someone finally asks: “Wait, are we even talking about the same type of data here?”

    The confusion is real. And expensive.

    After publishing the Authority Rule framework last week – the idea that master versus reference data is fundamentally about authority, not attributes – several people pointed out the exact source of confusion:

    The dropdown is lying to you.

    Two Identical Containers, Opposite Authority

    Open your metadata catalog. Look at everything labeled “reference data.”

    I’d bet a significant portion of it isn’t reference data at all.

    Here’s what I mean.

    Your system has a country code dropdown:

    • GRC – Greece
    • DEU – Germany
    • USA – United States
    • JPN – Japan

    You maintain this in your database. You update it when countries change. You synchronize it across systems.

    But ISO owns these codes.

    I’ve seen what happens when someone decides to “fix” this. A Swedish developer used “SV” for Sweden. Made perfect sense to them – their country, their natural abbreviation.

    Except ISO assigned “SV” to El Salvador.

    When the company started selling there, they had to give El Salvador a different code. Now there are permanent mapping tables. Every external integration needs special handling. Every new developer gets confused by why Sweden and El Salvador have non-standard codes. The more complex your system estate, the bigger the problem compounds.

    The root cause to the problem: they tried to exercise authority they don’t have.

    You can’t wake up tomorrow and decide Greece should be coded differently. Well, you can in your internal systems. But ISO still publishes “GRC or GR.” Every other system still expects “GRC or GR”. Every industry standard still uses “GRC or GR.”

    You don’t own these definitions. That makes them reference data.

    Your system has a sales area dropdown:

    • UK-Enterprise – UK Enterprise accounts
    • UK-SMB – UK Small/Medium Business
    • DACH-Enterprise – Germany, Austria, Switzerland Enterprise
    • NORDICS-ALL – Nordic countries, all segments

    You created these territories. You defined the boundaries. You chose the codes.

    Tomorrow, you could:

    • Merge UK-Enterprise and UK-SMB into UK-ALL
    • Split DACH by industry vertical instead of company size
    • Add BENELUX-Enterprise for Belgium, the Netherlands, and Luxembourg
    • Rename everything to match a new organizational structure

    And everyone in your organization must accept these changes. Your CRM updates. Your reporting adapts. Your sales teams realign. Your compensation plans adjust.

    You own these definitions. That makes them master data.

    The Format Trap

    Look at those two examples again.

    Same format: Dropdown list

    Same structure: Code + Description

    Same maintenance: Regular database updates

    Same usage: Referenced across multiple systems

    Completely different authority relationships.

    This is why format-based classification fails.

    For decades, we’ve said:

    • Lookup table? → Reference data
    • Dropdown values? → Reference data
    • Code tables? → Reference data
    • Low volume, high reuse? → Reference data

    We classified by what data looks like, not by who has the power to define it.

    Why I Started Questioning Format-Based Classification

    I kept noticing the pattern: meetings where smart people couldn’t agree on classification because they were arguing about different things.

    One person focused on format: “It’s in a dropdown, so it’s reference data.”

    Another focused on source: “We maintain it, so it’s master data.”

    A third focused on usage: “Multiple systems use it, so it’s reference data.”

    None of these attributes provided a clear distinction.

    I started looking for similarities and differences. What’s actually the same between country codes and sales areas? What’s fundamentally different?

    Not the container – both dropdowns.

    Not the maintenance pattern – both regularly updated.

    Not the importance – both critical to business operations.

    The difference is who has the authority to define what these codes mean.

    ISO for country codes. You for sales areas.

    Once I saw that, everything else fell into place.

    What Practitioners Are Discovering

    When I published the Authority Rule last week, Mark Berford – an Enterprise Data Architect with over 30 years of experience and DAMA membership – immediately recognized this pattern:

    “Traditionally, a list of possible values for a ‘customer type’ master data attribute is defined as reference data rather than master data. However these are still within ‘your’ authority to define, so I’m inclined to call [them master data].”

    He’s working through decades of format-based classification and seeing why authority provides the clearer distinction.

    Yogesh Poddar, a Product Owner in Digital Transformation, explained where the confusion originates:

    “Perhaps the confusion occurs due to the allocation of an additional internal unique identifier to instances of ref data – like Currency or Country codes. This could lead some to believe that since they have allocated their own identifier (to what is external data) that data is to be considered Master.”

    The presentation layer – how we store and display data internally – obscures the authority relationship underneath.

    The Authority Rule Applied to Dropdowns

    Stop classifying by format, instead remember this:

    Master: you can redefine it and only you need to agree.

    Reference: if you redefine it, the world won’t accept it.

    Apply this systematically to your “reference data” catalog:

    Reference Data (External Authority):

    • Country codes (ISO 3166)
    • Currency codes (ISO 4217)
    • Tax form codes (IRS, HMRC, etc.)
    • Industry classification codes (NAICS, SIC, etc.)

    You monitor external changes. You ensure compliance. You can’t redefine them.

    Master Data (Your Authority):

    • Sales area codes
    • Customer type codes
    • Department codes
    • Product category codes
    • Internal project codes

    You create, modify, and retire these based on business needs. You can ensure compliance in your company.

    The dropdown format is irrelevant. Authority determines classification.

    Steps to Improve Your Understanding

    Step 1: Audit Your “Reference Data”

    Go through your metadata catalog.

    For everything labeled “reference data,” ask: “Who has the authority to define what this means?”

    External organization (ISO, government, industry body) → Actually reference data

    Your organization → Actually master data, misclassified

    It wouldn’t surprise me if 40-60% of what’s labeled “reference data” in most enterprises is actually master data hiding in dropdowns.

    Step 2: Create Three Categories

    Reference Data: External authority defines, you monitor and comply

    • Examples: ISO codes, government regulations, industry standards

    Master Data: Your authority defines what everyone in your company must follow

    • Examples: Customer segments, territories, internal categories

    Lookup Data: The presentation format (can contain either type)

    • Examples: Dropdown lists, code tables, lookup tables

    The Container Is Irrelevant

    Dropdowns don’t lie. They present data consistently.

    But we lie to ourselves when we assume format determines classification.

    The dropdown is the container. Authority is what matters.

    Country codes and sales areas look identical in your UI. But you control one completely and the other not at all.

    Classify them differently. Govern them differently. Integrate them differently.

    Because who has the power to define what something means – that’s the line that actually matters.

    What’s Next

    This distinction between presentation and authority becomes even more important when examining layered authority relationships:

    • Tax codes (reference) vs tax rates (reference) vs tax configuration (master)
    • Currency codes (reference) vs trading currencies (master)
    • When your master data becomes someone else’s reference through contracts

    I’ll explore these complex cases in upcoming posts.

    But start with your dropdowns.

    Audit what you’ve labeled “reference data.” Apply the authority test. I’d bet you’ll find master data that’s been ignored because it was hiding in a lookup table.

    The Authority Rule cuts through format to reveal authority underneath.

    And authority – not format – determines what data actually is.

    This is part of a series on the Authority Rule framework for distinguishing master and reference data. The framework emerged from looking for similarities and differences across domains – the same pattern recognition approach that helped me understand art history, identity systems, and now data classification.

    Next week: “Just Because You Master It Doesn’t Mean You Own It” – why maintaining reference data in your systems doesn’t transfer ownership to you.

    What dropdowns in your organization are hiding master data behind a “reference data” label?

    Share your examples – I’m documenting these patterns for a book on the Authority Rule, and your real-world cases might make it into the final manuscript.