Data Authority Rule

Tag: Reference Data

  • Is there a hidden cost in vendor contracts: Reference Data?

    Micronesia potentially broke our system.

    Not catastrophically. Just… wrong. A Business Analyst flagged it. One potential data mismatch in a system we’d already used for years, now maybe causing issues with data mapping.

    It reminded me of the Sweden/El Salvador disaster from Post 2. A Swedish developer picked “SV” for Sweden, not knowing ISO had assigned it to El Salvador. Years of mapping tables to fix someone else’s assumption.

    Over the weekend, I started thinking about every procurement process I’d been part of.

    We never evaluated reference data standards.

    Not once.

    What I Evaluated (And What I Missed)

    At EDS, I evaluated vendor systems as the business expert on procurement teams. At Catalyst Housing, I led procurement projects.

    We checked everything. Functionality. Integration architecture. Security. Implementation timeline. Commercial terms. Vendor stability.

    Everything except reference data standards.

    Not because I didn’t care. Because it seemed obvious they’d be right.

    The Impact Cascade You Didn’t Price In

    When a vendor doesn’t use ISO standards, you’re not just buying “some integration work.” You’re buying consequences that ripple through your entire technology estate.

    Initial impact: Someone builds mapping tables. Vendor codes to ISO. Every vendor update/upgrade, you might need to update the mappings. Every ISO change, you update. Forever.

    Your compliance checking service uses ISO standards. Now you need transformation logic. Test cases. Exception handling. What happens when the mapping fails?

    Every new integration: Another mapping layer. More transformation logic. Compatibility testing with existing mappings. Documentation updates that future teams will need.

    Every new vendor: Three vendor systems, three different definitions of “Micronesia”. System A: “Micronesia”. System B: “FM” (ISO code, wrong mapping). System C: “FSM” (wrong definition). Three mapping tables. Not to ISO—to each other. Testing matrix multiplication. Exception handling for mismatches between systems.

    Test automation becomes a nightmare. Which version of “Micronesia” does each test case need? Mock data must account for every vendor’s definitions. Automated regression suites fail when mapping changes. CI/CD pipelines need transformation validation. Every automated test touching reference data needs vendor-specific variants.

    Operational impact: Support tickets when data doesn’t match. Manual workarounds when automation fails. Training new team members on “why we do it this way”. Knowledge loss when key people leave.

    Compliance and audit: Explaining to regulators why systems define data differently. Control weakness findings. Remediation plans. Annual re-findings when nothing fundamentally changes.

    Strategic constraints: New compliance requirements require integration work before implementation. New analytics platforms need mapping before they’re useful. API integrations to partners delayed by transformation complexity. Technical debt that makes every future decision harder.

    The costs aren’t just money. They’re velocity. Opportunity. Strategic flexibility.

    And they compound forever.

    What Should Change

    This should be an explicit evaluation criterion. Not buried in technical architecture review. Not assumed. Scored.

    Before vendor selection, ask which reference data standards they use. ISO 3166 for countries. ISO 4217 for currencies. ISO 639 for languages. Industry standards like ACORD, SWIFT, HL7.

    Then ask how they maintain them. Automatic feed from authoritative source? Manual updates—how often, who’s responsible? Custom definitions—where’s the documented mapping?

    Ask where they deviate from standards. Which entities use non-standard codes? Why? Legacy system? Customer request? Deliberate choice? What’s the mapping approach? Only in the UI?

    Ask how they handle updates. New country codes from ISO? Currency changes like Bulgaria joining the Euro? Deprecated codes?

    Ask what integration support they provide. Pre-built mappings to standards? Documentation of code definitions? Transformation services?

    If vendors can’t answer clearly, price in the integration cost.

    Why I Didn’t See This Coming

    I studied Economics. You use ISO country codes, ISO currency codes, standardized data definitions. Otherwise analysis is impossible. You can’t compare GDP across countries if everyone defines “country” differently.

    Most systems do use ISO standards. Countries. Currencies. Languages. All the reference data is correct.

    When your academic background and your first decade of professional experience both assume standards compliance, you don’t question it.

    Why would you? These are professional software vendors building enterprise systems. This is foundational.

    Except it’s not foundational to everyone.

    I didn’t think to ask during procurement because I’d never encountered a system that got it wrong.

    The Conversation with Procurement

    If you’re a Business Architect, Enterprise Architect, or data professional reading this, you might be thinking: “Yes! This! How do I get procurement to care?”

    Frame it as risk management, not technical detail.

    “We’re evaluating a vendor that could create ongoing integration costs because they don’t use industry standards for reference data. Should we price this into the commercial negotiation?”

    Make it a standard RFP question.

    “I drafted some questions about reference data standards compliance. Could we add these to the technical architecture section of our RFP template? It’ll help us identify hidden costs earlier.”

    Show the business impact.

    “Three vendor systems define countries differently. When we try to implement compliance checking, we’ll need months of integration work. Could we evaluate reference data standards in future procurements to avoid this?”

    Offer to help.

    “I can review technical architecture sections of vendor responses specifically for reference data compliance. It takes me thirty minutes per vendor and could save us significant integration costs.”

    Don’t make it about governance. Don’t make it about data purity. Make it about cost, risk, and integration complexity.

    Procurement teams manage cost and risk every day. Give them the business case.

    What I’d Do Differently Now

    If I were leading a procurement initiative today, reference data standards would be an explicit evaluation criterion.

    Not a nice-to-have. A scored requirement.

    Compliant with ISO/industry standards: Full marks.

    Custom codes with documented mapping: Partial marks, priced accordingly.

    Custom codes with no mapping plan: Major red flag.

    Because I’ve seen the costs. I’ve watched integration projects stall on data transformation. I’ve heard of test automation grinding to a halt because mock data needs multiple versions for the same country.

    The Authority Rule taught me: You don’t own reference data. But you own the consequences of choosing vendors who pretend they do.

    What You Can Do

    If you’re in procurement: Add reference data standards compliance to your evaluation criteria. Ask vendors to document their approach. Price non-compliance into commercial terms.

    If you’re a Business Architect or Enterprise Architect: Review your vendor landscape. Document which systems use non-standard codes. Quantify the integration impact across the areas that touch: transformation, testing, operations, compliance, strategy. Take this to procurement with a business case.

    If you’re a vendor: Understand that your customers pay forever for your architectural choices. Using ISO standards isn’t gold-plating. It’s reducing your customers’ total cost of ownership.

    If you’re buying systems off the shelf: Before you sign that contract, ask: “Which reference data standards do you use?” If they can’t answer clearly, you’re buying technical debt.

    The Micronesia conversation started this thinking. But it applies to every vendor system that doesn’t use reference data standards as its internal keys.

    The costs are hidden. The consequences are long-term. And the decision is made during procurement, often without anyone realizing it matters.

    I didn’t realize it earlier in my career.

    I realize it now.

    This post is part of The Authority Rule series exploring how authority patterns determine data classification and governance. The framework emerged from real-world experience building enterprise data architecture across multiple industries.

    Read the full series at authorityrule.com/

  • The True Cost of Ignoring Reference Data

    Post 5 of The Authority Rule Series

    When one “innocent” deviation from an ISO standard costs thousands (or more) every year.

    A Swedish developer made a reasonable decision. Their system needed country codes. Sweden is “Sverige” in Swedish. The natural abbreviation is “SV.” So they coded Sweden as “SV” in the database.

    Seemed perfectly logical. Got the project done. Moved on.

    Except ISO 3166 assigns “SV” to El Salvador.

    What Happened Next

    When the company started selling to El Salvador, they hit a wall. “SV” was already taken. So El Salvador got a different code, which meant permanent mapping tables in every integration. The data warehouse team discovered this variation years later when conforming data from multiple systems, and by then, the original developer was gone. The decision wasn’t documented; it seemed obvious at the time.

    Every migration touched this issue. Every integration required mapping logic. Every data warehouse layer needed transformation rules for fifteen years and counting.

    This wasn’t malicious or incompetent. It was one reasonable person making one local decision under project deadline pressure.

    The problem: Nobody told them ISO has authority over country codes.

    How It Really Happened

    Here’s what was missing: No one had decided “we use ISO 3166 for country codes.” No one had documented that country codes have external authority. QA had no policy to check against. Architecture hadn’t defined the pattern; they might not even have existed at the time of this project. So when project pressure hit and the developer needed a solution, they made the call themselves.

    Reasonable. Local. Wrong authority level.

    The failure wasn’t the developer’s. It was organizational—no one owned the decision about which external standards to follow.

    The Lifecycle Cost Nobody Captures

    Business cases model three to five years of maintenance. But systems run for fifteen to twenty years, or more, and this single ‘innocent’ decision touches every part of the software lifecycle.

    In development, you need permanent mapping tables in every system that integrates.

    During integration, every external connection requires special handling—forever.

    In the data warehouse, someone years later has to discover this variation when conforming data from multiple systems, often without documentation explaining why it exists.

    New developers are likely to assume the custom code is standard and are at risk of propagating the error.

    During migration, you have to remember, discover, or reverse-engineer the mapping, or everything breaks.

    The business case said three years. The system ran for twenty. One innocent decision. Decades of compounding technical debt.

    Where Responsibility Sits

    Someone must own the decision about which external standards the organization follows. If you have a Chief Data Officer, this sits in their domain. If you don’t have a CDO it is likely to be the Enterprise Architecture team. If you have neither, someone still needs to be responsible; in small organizations, it might be the Head of IT or Tech Lead.

    It doesn’t matter who. It matters that someone owns it.

    That role decides: “We use ISO 3166 for country codes. Non-negotiable.” Then QA checks compliance, and developers know they can’t redefine Sweden.

    The Authority Rule Prevents This

    The Authority Rule asks: Who has the authority to define what this means?

    For country codes, can you redefine what “Sweden” should be coded as tomorrow? Actually, no. ISO 3166 has that authority—every external system expects ISO codes, every industry standard uses them, every data exchange requires them. You don’t own this definition. That makes it reference data.

    Which means you follow the external authority. You don’t redefine it, create “helpful” variations, or make it fit local preferences.

    One question. One moment of clarity. Years of technical debt prevented.

    What This Means Monday Morning

    Identify who owns external standards decisions in your organization—CDO, Architecture, CTO, someone must have this responsibility. Document which external authorities you follow: ISO 3166 for countries, ISO 4217 for currencies, SWIFT for bank identifiers. Create guardrails that prevent deviation through architectural patterns and QA checks. When developers ask “can we just use our own codes?” the answer is already documented.

    Recognize that reference data needs policy, not governance. No approval workflow. No committee discussion. Just a rule: Follow the external authority.

    Why This Matters

    The Swedish developer wasn’t wrong to want “SV.” They just didn’t know ISO already owned that decision, and nobody in the organization took responsibility for telling them.

    That one missing policy created technical debt that compounds annually across the entire enterprise for decades. When you ignore reference data, you don’t just create one mapping table; you create permanent complexity that touches every system, every integration, every migration, every new developer, for the entire lifecycle of your estate.

    The Authority Rule prevents this by asking one simple question that reveals where authority actually sits: Can you redefine this? No. Then follow the standard.

    The Authority Rule: Can you redefine what this means, and do you need others to accept your definition? If you need others to accept = reference data. If you don’t = master data.

    Read the full series at authorityrule.com/

  • Why Exchange Rates Are Master Data (Yes, Really)

    Post 4 of The Authority Rule Series

    “But Charlotte, exchange rates come from Reuters. Bloomberg. The ECB. They’re published externally. We don’t decide what EUR/USD is trading at—we just look it up. How can that possibly be master data?”

    I hear this objection constantly. And I understand it. Exchange rates feel like reference data. They exist in markets. Multiple authorities publish them. You can’t just make them up.

    But here’s the thing: Exchange rates are master data.

    And the confusion about this sends people looking for answers in the wrong places.

    The Authority Rule Question

    Let’s apply our test: Who has the authority to define what this means, and do you need others to accept that definition?

    For currency codes, ISO 4217 decides that Euro = EUR, US Dollar = USD. You cannot redefine EUR to mean something else. Every system in the world must accept ISO’s definitions.

    This is reference data.

    For exchange rates, you choose which source (Reuters? Bloomberg? ECB? Your bank?). You choose which timing (opening? closing? daily average? intraday?). You choose which methodology (spot rate? forward rate? adjusted for fees?). Nobody else needs to accept your choices.

    This is master data.

    What You Actually Control

    When you “use an exchange rate,” you’re making four business decisions:

    1. Source authority: “We use Bloomberg rates.”
    2. Temporal authority: “We take the 4 pm London close”
    3. Methodological authority: “We use bid-side for payments, mid-side for reporting.”
    4. Exception authority: “During market disruption, we use yesterday’s rate.”

    Each of those is your choice.

    Your business decision.

    Your definition.

    The rate Bloomberg publishes at 4 pm is a fact. Which rate you use for which purpose? That’s your policy.

    Where Authority Actually Sits

    Here’s what matters most.

    Exchange rate policy sits with your CFO and C-Suite, not with data governance or IT. It’s not a data steward decision. It’s not a reference data maintenance task. It’s not an IT configuration choice.

    It’s a business decision about financial policy. When someone asks, “Which exchange rate should we use for this new product line?” the answer isn’t in a data governance committee. It’s in a conversation with Finance leadership or the C-suite about risk tolerance, accounting requirements, and business strategy.

    When the classification is confused:

    Finance teams submit “data change requests” for what should be executive decisions.

    Data governance committees debate financial policy they shouldn’t own.

    IT teams make business decisions by default when configuring rate feeds.

    Business decisions get stuck in data maintenance workflows.

    The Real-World Test

    Tomorrow, your CFO can say: “We’re switching from Reuters to Bloomberg, and we’re moving from daily close to intraday rates for all FX trades over €1M.”

    And they can just… do it.

    You need to comply with regulatory requirements – if regulations say “use observable market rates,” you must use recognized sources. But within those constraints, the specific choices are yours. The regulator doesn’t approve that you switched from Reuters to Bloomberg. They just care that both are legitimate market sources that meet their requirements. Your external auditors don’t verify which timing convention you chose. They verify that your chosen approach is consistently applied and appropriate.

    The regulatory framework is reference data (you must follow it).

    Your implementation within that framework is master data (you control the specifics).

    If your CFO said, “We’re redefining EUR to mean Japanese Yen,” regulators would shut you down immediately. You can’t redefine currency codes because ISO has that authority, and regulators require you to follow ISO standards.

    That’s reference data – an external authority you must accept.

    Why Classification Matters

    Knowing what it is tells you where to seek your answer.

    When someone asks, “Can we change how we handle exchange rates?”:

    If you think it’s reference data:

    • Data governance committees
    • Reference data stewards
    • IT maintenance teams
    • External source verification

    If you know it’s master data:

    • CFO and Finance leadership
    • Business policy owners
    • Risk management
    • Strategic decision makers

    The classification doesn’t just organize your data catalog.

    It tells you who has the authority to make decisions. Which tells you where to go for answers.

    Common Confusions

    “But the rate exists independently of us!”, “But we have to use market rates for compliance!”

    You choose which source, which timing, which methodology. Compliance constrains; it doesn’t eliminate your authority.

    “But everyone uses the same rates!”

    They don’t. Some use opening, some closing, some averages. Some use mid-market for reporting but bank rates for transactions. The variety proves the authority is distributed.

    What About Rate Tables?

    You maintain a table of exchange rates in your database.

    Doesn’t that make it reference data?

    No. (See Post 3: “Just Because You Master It…”)

    You’re maintaining your copy of your business decision about which rates to use. The fact that you update it daily doesn’t change who has authority over what the data means.

    The rate value came from an external source (that’s a fact). Which source you used is your decision (that’s policy). When you captured it is your decision (that’s policy). How you apply it is your decision (that’s policy). Whether to override it in specific cases is your decision (that’s policy).

    All policy. All yours. All master data.

    And all CFO authority, not data governance authority.

    The Governance Implication

    If you govern exchange rates as reference data:

    • Finance decisions route through data committees
    • Business policy becomes “data change requests”
    • CFO authority gets obscured by process
    • Time wasted seeking wrong approvals

    If you govern exchange rates as master data:

    • Financial policy sits with Finance leadership
    • Business decisions flow appropriately
    • Authority is transparent and efficient
    • People know who to talk to

    The Pattern

    This pattern repeats everywhere.

    Tax codes = reference (government decides) → monitor external changes

    Tax rates = reference (government decides) → monitor external changes

    Your tax configuration = master (Finance decides) → business approval workflow

    Security identifiers (ISIN, CUSIP) = reference (authorities decide) → monitor standards

    Security prices = fact in markets → capture data

    Which prices you use for valuation = master (CFO decides) → financial policy

    Country codes = reference (ISO decides) → follow standards

    Your market segmentation = master (executives decide) → strategy decision

    The external fact existing doesn’t make it reference data. Your authority over how you use it makes it master data.

    And that authority lives somewhere specific in your organization.

    What This Means For You Today:

    Stop routing rate policy questions through data governance.

    Document who owns rate sourcing methodology.

    Separate rate values from rate policy in your architecture.

    When someone asks “which rate should we use,” redirect them to Finance leadership.

    Recognize that knowing the source and type matters more than the label – but knowing the label tells you where to go for decisions.

    Why This Matters

    The confusion doesn’t just clutter your data catalog.

    It sends people to the wrong decision-makers. When Finance teams think exchange rates are “just reference data,” they defer to IT or data governance for decisions that should be theirs.

    When data teams think exchange rates are reference data, they implement what should be executive-level financial policy.

    The Authority Rule cuts through the confusion: Can you redefine your rate sourcing methodology tomorrow? Yes. Do you need anyone else to accept it? No. It’s master data. And that means the authority sits with your CFO, not your data steward.

    The external fact that rates exist in markets doesn’t eliminate your authority over how you use them.

    And recognizing where that authority lives tells you exactly where to go for answers.

    Next Week: The True Cost of Ignoring Reference Data – When one “innocent” deviation from an ISO standard costs thousands every year

    The Authority Rule: Can you redefine what this means, and do you need others to accept your definition? If you need others to accept = reference data. If you don’t = master data.

    Read the full series at authorityrule.com/

  • 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.