First thing first: I think I went a little hard on Single Source of Truth (SSOT).
A lot of people read my last article on Distributed Coherence and took it as a rejection of authoritative content sources, the places where the real information sits. Reading it back, that is totally understandable. But I don’t want to conflate things between SSOT and having authoritative sources with real version control and approvals.
Before diving into today’s article, let’s clarify these two terms tripping up a lot of content governance conversations:
Single Source of Truth (SSOT)
This implies one canonical version that publishes everywhere unchanged. It’s a distribution model—create once, push to all channels.
- “Use these exact words everywhere”
- “Every audience gets the same voice”
- “Central approval for all content”
- “One style guide that works for investors, customers, and employees”
- Assumption Same content works everywhere
- Flow: Source → identical copies
- Failure mode: Inappropriate content in wrong contexts
- Governance: Control all outputs
Authoritative Source
This is different. It’s the recognized origin for specific information—the place you go to verify facts or get approved language. But it doesn’t assume that content flows unchanged from source to surface.
- Product specifications: One price, one SKU, one official name
- Legal language: Exact regulatory disclosures
- Brand assets: Official logos, approved colors
- Technical truth: API endpoints, system requirements
- Assumption: Source Same facts apply everywhere; expression adapts
- Flow: Source → contextual implementations
- Failure mode: Drift from authoritative facts
- Governance: Control all outputs Verify alignment with source
An Example for Retail
I work at [a major retailer] in the loyalty space. right now, information about loyalty logos, illustrations, approved value prop copy, and legal footnotes all lives in one mega-PDF...owned by our business strategy partners. This isn’t the deal set-up. The POC running the PDF is very “consistency everywhere,” and the PDF has been neglected due to 3+ reorgs this year.
Meanwhile, the folks *writing* for the products have teased out the limitations we need to know, like what a disclosure is specifically tied to or what terminology doesn’t resonate or what guest sub-types there are—and we’re trying to consolidate this info somewhere, without creating too much rework. a messaging architecture and content testing document are in the works. now, i’m wondering: what product documentation would best suit a distributed coherence model? does the variation log scale? how do YOU teach folks about the core of the product before empowering them to make coherent variations?
This is so juicy it just spawned another post!
The corporate content dream: One source of truth. One voice. One set of rules that works everywhere.
The corporate content reality: A 200-page brand book that sits in a shared drive while everyone writes whatever they want anyway.
Here’s what I learned: Sometimes the problem isn’t that people won’t follow the rules. It’s that you’re trying to solve a distributed problem with a centralized solution.
The mega-PDF problem isn’t that it’s authoritative—it’s that it’s treated as SSOT. Legal disclosures should have an authoritative source that controls exact language. Value propositions should have an authoritative source for core meaning. But neither should publish unchanged across every context. So our definitions of SSOT and Authoritative Sources means that mega-PDF was doing all of the jobs when it’s only build for a few. Much like American policing, but that’s another story for another time.
Distributed coherence keeps authoritative sources where they belong while enabling contextual adaptation. The Reference Registry below is an authoritative source. The Principle Cards reference authoritative positioning but don’t enforce identical execution.
The goal isn’t to win an argument—it’s to show that you share their underlying concern (consistency, reliability, governance) while offering a more realistic path to achieving it.
This example architecture separates content by type and governance need, replacing the single mega-PDF with purpose-built documentation that actually scales.
Always know before you go
Before you start building it out, always start with an assessment of where you are:
- Risk assessment: What happens if this content is inconsistent?
- Audience analysis: Do you have genuinely different audiences or just one audience on different channels?
- Decision velocity: How fast do teams need to move?
- Governance capacity: Can you review everything or need to trust distributed decisions?
- Authoritative sources audit: What needs to be factually accurate vs. contextually appropriate?
Make a documentation map
Sometimes our own content strategy needs a content strategy! Think of your mega-PDF and how it can be set up in formats appropriate for how they’re being used and maintained.
The mega-PDF is trying to be many things at once. Split it:
- Legal/disclosures → structured registry with trigger conditions
- Value props → principle cards (the *why* and *when*, not just approved copy)
- Visual assets → DAM
- Writer learnings → variation rationale log
The variation log scales product info at the pattern level, not individual instances. You’re documenting “checkout context prioritizes action over explanation”, not every checkout string.
Your brand assets are managed in their usual place, your legal noticed can be structured and stored for reuse in a database. Your principles you can point to for people on your team sites, and your rationales and terms can be maintained by your core team as a living repo or searchable tool (e.g., “Is it ‘sign in’ or ‘sign-in’ or ‘signin’?”).
1. Reference Registry: Legal & Compliance Content
This is where authoritative source genuinely applies. Legal language needs precise control—the exact words matter, and there’s one place to verify them.
But looky: even here, we’re not doing SSOT. The registry is authoritative for the language, but placement, surrounding context, and integration still adapt per surface.
Structure
DISCLOSURE: Loyalty-Card-Link-01
├── Trigger condition: When linking loyalty membership to store card
├── Required placement: Below CTA, before confirmation
├── Exact language: [locked text from Legal]
├── Last reviewed: 2024-Q3
├── Tied to: Reg E, Card Agreement Section 4.2
└── Context notes: Cannot be paraphrased; can adjust surrounding content
What makes this different from the mega-PDF
- Searchable by trigger condition, not buried in a 40-page doc
- Clear ownership trail—who approved, when, why
- Separation of locked vs. flexible—writers know exactly what they can’t touch
- Authoritative without being SSOT—the disclosure is canonical; its integration is contextual
Migration path
Pull all legal footnotes from the mega-PDF into this structure. This is low-risk, high-value, and actually gives the Business Strategy POC better consistency for the stuff that truly matters.
2. Principle Cards: Core Positioning
This replaces “approved value prop copy” with something writers can actually apply.
The Principle Cards reference authoritative positioning (the core meaning that business strategy owns) but don’t enforce identical execution. They’re governance through principles, not control through templates.
Teach the coherence markers first, product specifics last. Once writers internalize how your loyalty team talks to guests, they need less prescription than you’d think.
Card Template
PRINCIPLE CARD: [Name]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
WHAT TO COMMUNICATE
[The core meaning that must come through, regardless of execution]
[This is the authoritative positioning—owned by Business Strategy]
WHEN TO EMPHASIZE
• Context A: [specific guidance]
• Context B: [specific guidance]
• Context C: [specific guidance]
WHAT TO AVOID
• [Anti-patterns, language that tested poorly, common mistakes]
COHERENCE MARKERS
• [Non-negotiables that make this recognizably your brand's loyalty content]
EXAMPLE RANGE
Minimal: "[shortest viable version]"
Standard: "[typical execution]"
Comprehensive: "[when you have space and attention]"
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Example: Earnings Value Prop
PRINCIPLE CARD: Loyalty Earnings Value Proposition
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
WHAT TO COMMUNICATE
Earnings accumulate through normal shopping behavior and translate
to real value without complicated requirements.
WHEN TO EMPHASIZE
• Acquisition moments: Lead with simplicity ("just shop")
• Low balance: Emphasize accumulation ("every trip adds up")
• High balance: Emphasize redemption ("ready to use")
• Checkout: Emphasize immediacy ("use now or save for later")
• Retention: Emphasize history ("you've earned X this year")
WHAT TO AVOID
• "Free money" framing (tested as unbelievable)
• Point-expiration anxiety without clear action path
• Complicated earn-rate math in high-velocity contexts
• Implying customers must change shopping behavior
COHERENCE MARKERS
• Customer has control (choice language, not obligation language)
• Value feels achievable, not aspirational
• Tone: helpful neighbor, not salesperson
EXAMPLE RANGE
Minimal: "1% back on every trip"
Standard: "Earn 1% back when you shop, use it when you're ready"
Comprehensive: "Every trip earns you 1% back in loyalty earnings.
Use your earnings at checkout whenever you want—there's no minimum
and no expiration while your account is active."
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Example: Redemption Mechanics
PRINCIPLE CARD: Redemption Experience
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
WHAT TO COMMUNICATE
Using earnings is simple, flexible, and controlled by the customer.
WHEN TO EMPHASIZE
• Pre-checkout: Awareness that earnings exist and are usable
• At checkout: Clear action to apply, clear result
• Post-checkout: Confirmation of what was used, what remains
• Low balance: Frame as "building toward" not "not enough"
• Partial redemption: Customer chose this; don't second-guess
WHAT TO AVOID
• "Redeem" as primary verb (tested as transactional/program-y)
• Suggesting full-balance redemption is expected or better
• Hiding remaining balance after partial use
• Making customers calculate—show the math result, not the formula
COHERENCE MARKERS
• Customer is in control of if/when/how much
• Earnings feel like *their* money, not the brand's gift
• Process should feel lighter than using a coupon, not heavier
EXAMPLE RANGE
Minimal: "Use $4.50 in earnings"
Standard: "You have $4.50 to use today. Apply all or some—it's up to you."
Comprehensive: "You've built up $4.50 in loyalty earnings. Want to use
some today? Slide to choose your amount—whatever you don't use stays
in your account for next time."
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
3. Variation Rationale Log
This captures why content differs across contexts. It’s institutional memory that makes future decisions smarter.
This is where distributed coherence proves its value: instead of pretending content is the same everywhere (SSOT) or fragmenting into chaos, you document the principled reasons for variation.
Entry Template
VARIATION RATIONALE: [Topic]
Date: [When documented]
Contributors: [Who provided insight]
CONTEXT DIFFERENCE
[Where does this content appear differently, and what's different about those contexts?]
THE VARIATION
[What specifically changes?]
WHY IT WORKS THIS WAY
[Research, testing, or principled reasoning behind the difference]
WHAT WE TRIED THAT DIDN'T WORK
[Failed approaches and why they failed—prevents reinventing the wheel]
IMPLICATIONS FOR NEW CONTEXTS
[How to think about this if a new channel/surface emerges]
Example Entry: Earnings Balance Display
VARIATION RATIONALE: Earnings Balance Display
Date: 2024-09
Contributors: [Content team], [Research insights from Q2 study]
CONTEXT DIFFERENCE
Balance displays differently across app home, checkout, and account pages.
These contexts have different customer mental states and needs.
THE VARIATION
• App home: Round to nearest dollar ("About $12 to use")
• Checkout: Exact to cent ("$12.47 available")
• Account: Exact + history ("$12.47 available • $47.82 earned this year")
WHY IT WORKS THIS WAY
App home is glanceable—precision creates cognitive load without benefit.
Customers aren't making decisions there, just checking status.
Checkout is transactional—customers need exact numbers to make apply/don't-apply
decisions and to verify the math worked correctly.
Account is reflective—customers visiting account pages want details and history.
The "earned this year" framing tested well for reinforcing program value
without feeling like a sales pitch.
WHAT WE TRIED THAT DIDN'T WORK
• Exact cents everywhere: Created false precision anxiety ("why is it $12.47
and not $12.50?") in non-transactional contexts
• Rounded everywhere: Caused checkout confusion when applied amount didn't
match displayed amount
• "Points" instead of dollars: Every test showed dollar-value framing wins
IMPLICATIONS FOR NEW CONTEXTS
• High-velocity, glanceable contexts: Round
• Decision-point contexts: Exact
• Reflective/engagement contexts: Exact + trajectory info
Example Entry: Customer Sub-Type Messaging
VARIATION RATIONALE: New vs. Established Customer Framing
Date: 2024-10
Contributors: [Content team], [Lifecycle marketing insights]
CONTEXT DIFFERENCE
Loyalty messaging varies based on customer tenure and engagement level.
A new member needs different content than a 3-year active member.
THE VARIATION
• New customers: Lead with "how it works" before "what you've earned"
• Established low-engagement: Lead with "what you're missing"
• Established high-engagement: Lead with "what you've built"
WHY IT WORKS THIS WAY
New customers don't have mental model yet—starting with balance before
explaining accumulation creates confusion ("wait, where did this come from?").
Established but low-engagement customers have mental model but aren't using it—
showing unredeemed value or missed opportunities can reactivate without
feeling punitive.
High-engagement customers know exactly how it works—celebrating their
history reinforces the relationship without being patronizing.
WHAT WE TRIED THAT DIDN'T WORK
• Same "welcome" framing for everyone: Established customers found it
insulting/confusing
• Loss framing for everyone ("you're missing out"): New customers felt
pressured; high-engagement customers felt unappreciated
• Earn-rate details for new customers: Too much too soon—save for
account pages where they're actively exploring
IMPLICATIONS FOR NEW CONTEXTS
When building new surfaces, determine: does customer tenure matter here?
If yes, can we detect it? If we can't detect it, default to "established"
framing—it's less condescending to explain basics to someone who knows
than to assume ignorance of someone who doesn't.
4. Terminology Guide
Lighter-weight than principle cards, this captures specific language learnings.
Structure
TERM: [Word or phrase]
STATUS: ✓ Use | ⚠️ Use carefully | ✗ Avoid
CONTEXT: [Where this applies]
NOTES: [Why, what to use instead, nuance]
Example Entries
TERM: Redeem
STATUS: ⚠️ Use carefully
CONTEXT: Checkout and account contexts only
NOTES: Tested as too transactional/program-y for marketing contexts.
In checkout, it's expected. In email, prefer "use your earnings."
TERM: Points
STATUS: ✗ Avoid
CONTEXT: All customer-facing content
NOTES: Program uses dollar-value framing, not points. Legacy program
used points. Some customers still say "points"—that's fine, but
we don't reinforce it. Use "earnings" or "[Program] earnings."
TERM: Wallet
STATUS: ⚠️ Use carefully
CONTEXT: Depends on surface
NOTES: App uses "Wallet" as a navigation label. Don't use "wallet" as
a metaphor elsewhere—creates confusion about whether it's a
feature or a concept.
TERM: Savings
STATUS: ✓ Use
CONTEXT: Broad
NOTES: Works across contexts. Encompasses earnings, deals, coupons.
Good for aggregate messaging. Don't use when you need to be
specific about which savings type.
TERM: Benefits
STATUS: ✗ Avoid
CONTEXT: Value prop messaging
NOTES: Tested as generic/corporate. "Perks" tested slightly better
but still lukewarm. Prefer specific: "free delivery," "extra
savings," "birthday reward."
5. Decision Frameworks
These help writers navigate recurring tradeoffs without escalating every decision.
Framework: When to Reference Disclosures
DECISION FRAMEWORK: Disclosure Placement
ALWAYS INCLUDE (inline or immediate link):
• Legal requirements (see Reference Registry for triggers)
• Financial implications customer might not expect
• Limitations that would change customer decision
LINK TO DETAILS (not inline):
• Terms that elaborate but don't change decision
• Full legal language when summary is permitted
• Edge cases that apply to <5% of customers
OMIT (surface handles elsewhere):
• App-wide terms covered by app T&C acceptance
• Information available at clear next step
• Redundant disclosure (already shown in flow)
WHEN UNSURE:
Ask: "If a customer didn't see this, would they feel misled?"
Yes → Include or link
No → Probably safe to omit
Still unsure → Check Reference Registry for specific trigger
Framework: Personalization vs. Standardization
DECISION FRAMEWORK: When to Personalize Loyalty Content
PERSONALIZE WHEN:
• Customer tenure significantly changes what's relevant
• Balance/activity level changes appropriate framing
• Customer has expressed preference (notification settings, etc.)
• Context is 1:1 (email, app notification)
STANDARDIZE WHEN:
• Variation would create confusion ("why does this look different?")
• Legal/compliance requires consistent language
• Context is 1:many (marketing page, help content)
• Personalization data isn't reliable for this customer
BLEND (personalized element within standard frame):
• Checkout: Standard flow, personalized balance display
• Email: Standard template, personalized earnings callout
• App home: Standard layout, personalized "for you" module
Migration Path: Getting There From Here
Phase 1: Extract and Protect (Low Risk)
- Pull legal footnotes and disclosures into Reference Registry
- Document trigger conditions and ownership
- Sell this as “making compliance easier”—you’re strengthening the authoritative source, not challenging it
Phase 2: Capture Tribal Knowledge (Medium Risk)
- Interview writers—what do they know that isn’t documented?
- Start Variation Rationale Log with existing learnings
- Build Terminology Guide from “what we’ve learned doesn’t work”
- This doesn’t threaten the mega-PDF—it fills gaps the PDF can’t address
Phase 3: Build Forward-Looking System (Strategic)
- Develop Principle Cards from messaging architecture work
- Create Decision Frameworks from recurring escalations
- Pilot with one product area or content type
- Demonstrate value before proposing full replacement
Phase 4: Retire the PDF (Eventually)
- Brand assets move to proper DAM
- Reference content lives in Registry (authoritative source preserved)
- Principles and rationales live in your system
- PDF becomes historical artifact, not operational tool
How This Coexists With “Consistency Everywhere”
The consistency advocate’s goal is valid. This architecture delivers consistency better than the PDF by distinguishing between authoritative sources (which provide consistency of meaning) and SSOT (which falsely promises consistency of execution):
Their concern How this addresses it “Everyone uses different language” Principle Cards ensure same meaning; Terminology Guide prevents known failures “Legal requirements get missed” Reference Registry is a proper authoritative source—more reliable than ctrl+F in a PDF “We keep reinventing the wheel” Variation Rationale Log captures learnings permanently “No one reads the PDF” Modular docs get used because they’re findable and relevant “Things get out of date” Distributed ownership with clear update cycles beats single-owner neglect
The key reframe: “We’re not eliminating authoritative sources—we’re making them actually authoritative. And we’re stopping the fiction that authoritative means ‘copy-paste everywhere.’”
What you’re NOT doing
To be clear about scope, it’s always good to create bumpers:
- Not replacing brand guidelines (visual identity stays where it is)
- Not taking over legal compliance (Registry makes their job easier—it’s a better authoritative source)
- Not removing approval processes (just making them more targeted)
- Not adding bureaucracy (reducing it by enabling good decisions without escalation)
- Not eliminating consistency (achieving it through coherence rather than rigidity)
You’re building infrastructure that makes everyone’s job easier—including the ones you’re trying to win over, the consistency advocates.
Whew, that was a lot to absorb over leftovers and hot chocolate, but keep the questions coming. I hope that helps!
