Post 8 of The Authority Rule Series
Something didn’t fit.
I’d mapped out four authority types: Reference Data (external authority), Master Data (internal strategic), Master Records (internal operational), and Transactions (captured events). The framework worked well—until I hit contracts. Then nothing lined up cleanly.
Contracts.
They’re not quite transactions.
A payment transaction records an event—it happened on 15 December. A contract defines terms that govern the behavior, i.e., when and how often payments are due.
Contracts are a fifth authority type: Contractual Authority.
What Makes Contractual Authority Different
Contractual authority is bilateral or multilateral binding agreement.
Neither party can unilaterally change it. Your customer can’t rewrite the terms. You can’t rewrite them either.
Both must follow what was signed. Courts arbitrate disputes—when parties disagree on what the contract means, external authority interprets. Just like ISO interprets currency standards, courts interpret contractual terms.
It creates shared authoritative terms. Within the relationship, the contract functions as reference data both parties must follow. But unlike ISO standards, it only binds the signatories.
It’s immutable as a document.
Why This Matters in Insurance
I work in P&C insurance.
This distinction is fundamental to how we operate.
The policy document is contractual authority. It defines coverage, exclusions, limits, terms.
Once signed, both insurer and insured must follow it. Claims adjusters can’t just decide to pay something the policy excludes—they’re bound by the policy terms. Courts interpret ambiguous clauses when disputes arise. The contract governs what happens, not internal policy changes made after signing.
Premium payments are transactions.
They record what happened under the policy terms. Insured paid £500 on 1 January—that’s captured authority, it happened.
Claims are transactions governed by contractual authority. The claim event happened (transaction). Whether it’s covered depends on the policy terms (contractual authority).
Coverage definitions start as master data. Before the policy is sold, your coverage tiers, exclusions lists, and limits are internal master data. Management can change them tomorrow for new policies.
But once signed into a policy, they become contractual authority.
Now you can’t unilaterally change those definitions for this customer.
When Master Data Transforms
I see this transformation constantly.
Your product codes are master data. You control your product hierarchy. Management can restructure it tomorrow for new customers.
But write those codes into a multi-year supplier agreement?
Now they’re contractual authority. You can’t just “update the product hierarchy” without renegotiating contracts.
Your pricing structure is master data.
You decide how to price your services. But sign a three-year SLA with fixed prices? Those prices are contractual authority—you’re bound by what you signed.
Your service levels are master data. You define what “standard support” means internally. Include those definitions in customer contracts? They’re now contractual authority. The customer can hold you to your own definitions. Not your updated definitions—the ones you agreed to.
Your coverage tiers in insurance are master data internally. Define Bronze, Silver, Gold however you want. But underwrite a policy using those tiers? Contractual authority for that policy’s lifetime.
The Governance Trap
Companies miss this transformation all the time.
They see “master data change.”
They miss “contractual authority impact.”
Insurance company decides to update their household policy terms to exclude flood damage in high-risk zones. Sounds like a master data change—management decision, internal authority. But tens of thousands of existing policies have already been sold. Those are contractual authority. You can’t retroactively change coverage for signed policies—the old terms remain in force until renewal.
What looks like a simple master data update is actually dual governance.
New master data (updated policy template). Existing contractual authority (signed policies unchanged). You’re managing two versions until policies renew.
Software company restructures product hierarchy—”Enterprise” tier splits into “Enterprise Standard” and “Enterprise Plus.” Management approved. Seems straightforward.
But hundreds of enterprise customers have contracts.
Those contracts reference “Enterprise” with specific feature lists. Contractual authority.
You need contract amendments or grandfather clauses—not just a product hierarchy update.
The Test for Contractual Authority
Can you unilaterally redefine this tomorrow?
Your product hierarchy → Yes, management decides → Master Data
ISO currency codes → No, ISO decides → Reference Data
Signed contract terms → No, both parties agreed → Contractual Authority. The signed contract happened at a point in time—an immutable document, captured like a Transaction. But it creates ongoing binding authority, governs future behavior—unlike a Transaction.
Do others need to accept your redefinition?
Your sales territories → No, internal only → Master Data. Signed policy coverage → Yes, customer and courts must accept → Contractual Authority.
The Five Authority Types
External Authority (Reference Data):
- ISO, governments, regulators decide
- Universal or industry-wide
- You follow or you’re non-compliant
- Example: Currency codes, tax rates
Internal Strategic Authority (Master Data):
- Management decides
- Internal to your organization
- You can redefine unilaterally
- Example: Sales territories, product hierarchies
Internal Operational Authority (Master Records):
- Employees maintain within structures
- Day-to-day operations
- Must follow master data and reference data
- Example: Customer #12345, Product SKU ABC
Captured Authority (Transactions):
- What happened at a moment
- Immutable as an event
- Records the state of other data types
- Example: Invoices, payments, claims
Contractual Authority (Contracts):
- Bilateral/multilateral binding agreement
- Neither party can unilaterally change
- Courts arbitrate disputes
- Transforms your master data into binding terms
- Example: Policies, SLAs, supplier agreements
Each pattern requires different governance. Reference Data: Monitor and comply. Master Data: Management approval and impact analysis.
Master Records: Operational quality management.
Transactions: Audit and correction processes. Contractual Authority: Legal review, negotiation, and amendment processes. Don’t treat contract changes like data updates.
What This Means Monday Morning
Before signing contracts, review what master data you’re binding.
Product codes, pricing structures, service definitions—once they’re in signed contracts, they’re no longer just internal master data. You’ve transformed them.
Distinguish policy documents from policy transactions.
The policy is contractual authority. Premium payments are transactions under those terms.
Recognize you’re managing two versions.
New master data for future contracts. Existing contractual authority for signed agreements. Both need governance, but different governance—don’t confuse updating your product catalog with amending hundreds of customer contracts.
When updating master data, audit contractual impact. Which signed contracts reference this? Do you need amendments? Grandfather clauses? Migration plans?
Don’t treat contract changes like data updates.
Amending contractual authority requires negotiation, not just management approval.
The PDF Problem
Here’s where this gets practical.
The five authority types matter operationally.
Most contracts are PDFs.
Unstructured.
Unqueryable.
You want to restructure your product hierarchy. Management approves. Seems like a straightforward master data change. But which contracts reference those products?
You can’t query PDFs.
Someone has to manually read hundreds of contracts.
Or worse, you just make the change and hope nothing breaks.
You can’t ask “which contracts reference our Bronze coverage tier?” You’d have to read every policy document manually. You can’t analyze “what’s the impact of retiring product code PROD-100?” No database knows which contracts bind that code. You can’t audit “how many policies still use the old service level definitions?” The data exists in PDFs, not in queryable systems.
So when management wants to change master data, you can’t assess contractual authority impact.
You’re governing blind.
This is why AI tools that can extract contract data into structured formats like JSON, XML, or something else are becoming more common.
Tools that read PDFs, extract key terms, and make them queryable. It’s not a perfect solution—retrofitting is messy—but it’s better than nothing.
Insurance is slowly moving in this direction. Contract extraction tools. Structured policy data initiatives.
But most industries are still drowning in PDFs, unable to analyze which master data has transformed into contractual authority.
The framework shows why this matters. Being able to query your contracts would make it actionable.
Why The Five Types Matter
The Authority Rule started simple: Can you redefine it? Do others need to accept?
But every time I used it, I kept finding five patterns, not two: External (you follow), Internal Strategic (management decides), Internal Operational (employees execute), Captured (what happened), Contractual (bilaterally binding). Each pattern requires different governance—you can’t apply the same rules to all five types.
Reference Data: Monitor and comply.
Master Data: Management approval and impact analysis. Master Records: Operational quality management. Transactions: Audit and correction processes.
Contractual Authority: Legal review, negotiation, and amendment processes.
Get the authority pattern right, and governance becomes clear. Treat a signed contract like master data that you can change? Expect lawsuits. Treat your internal product hierarchy like contractual authority requiring customer approval? Paralysis.
This framework isn’t about data formats. It’s about authority patterns.
And contracts proved I needed a fifth type to capture bilateral binding authority.
The Authority Rule: Can you redefine what this means, and do you need others to accept your definition? The answer reveals which authority pattern you’re dealing with.
Leave a Reply