Source of Truth Creator v1.1

Purpose: Create Source of Truth documents that are epistemically calibrated and Clarity Gate-ready.

Core Question: "When someone reads this document, will they have accurate confidence in each claim?"

Core Principle: "A Source of Truth that overstates certainty is worse than no Source of Truth -- it creates false confidence. Calibration matters more than completeness."

Prior Art: This skill synthesizes established frameworks (GRADE, ICD 203, PRISMA, IIA Standards). Our contribution is practical accessibility, not new concepts. See docs/PRIOR_ART.md.

Origin: Extracted from Clarity Gate meta-verification (2025-12-21). When we ran Clarity Gate on its own Source of Truth document, we discovered failure modes specific to SoT creation. See: Clarity Gate SOURCE_OF_TRUTH.md

When to Use This Skill

Use when:

• Claims will be cited elsewhere
• Decisions depend on accuracy
• Document will be read by people who don't know your epistemic standards
• Creating authoritative reference for a project
• Consolidating research from multiple sources

User phrases that trigger this skill:

• "Create a source of truth for..."
• "Document the verified state of..."
• "I need an authoritative reference for..."
• "Consolidate this research into..."

Do NOT use when:

• Taking meeting notes (use simple markdown)
• Brainstorming (uncertainty is the point)
• Personal project logs (overkill)
• Quick summaries (no verification needed)
• Internal team scratchpads

For lightweight documentation, use plain markdown. This skill is for documents where epistemic rigor matters.

The Recursion Problem

Source of Truth documents face a unique challenge:

1. A Source of Truth claims to be "VERIFIED"
2. But verification requires... a Source of Truth
3. At some point, claims bottom out in human judgment

This skill doesn't solve the recursion -- it makes it visible.

The goal is not infinite regress verification. The goal is:

• Clear marking of WHERE claims bottom out
• Honest confidence levels for each claim type
• Visual calibration so readers don't over-trust

The Eight Failure Modes

These patterns emerged from meta-verification of the Clarity Gate Source of Truth document. Modes 1-5 were discovered during that verification; Mode 6 was identified during review as a common pattern.

1. THE VERIFIED HEADER TRAP

Problem: Document header says "Status: VERIFIED" but body contains estimates, hypotheticals, and acknowledged uncertainties.

Why it matters: Readers skim headers. A "VERIFIED" badge creates false confidence in all contents.

Fix: Always qualify the header status, or use the Verification Summary box.

2. THE INTERNAL MEASUREMENT TRAP

Problem: Internal measurements (timing, counts, informal tests) marked as "Verified" with the same formatting as externally-validated claims.

Why it matters: "12 seconds" from one informal run is not equal to "12 seconds" from rigorous benchmarking.

Fix: Add methodology notes: [MEASURED: n=X, conditions Y], [INFORMAL: single observation], [ESTIMATED: author judgment]

3. THE SELF-ASSESSMENT TRAP

Problem: Self-assigned scores (8.8/10, "High confidence") presented in tables that look like external validation.

Why it matters: Numeric scores trigger authority heuristics. "9.5/10" looks objective even when self-assigned.

Fix: Always label self-assessments explicitly in the table header or row.

4. THE ABSENCE-AS-PROOF TRAP

Problem: "No prior art found" marked as "Verified" when absence of evidence is not equal to evidence of absence.

Why it matters: A more thorough search might find what you missed. Gap claims are inherently uncertain.

Fix: Add epistemological caveat to all "X doesn't exist" claims.

5. THE ILLUSTRATIVE-AS-DATA TRAP

Problem: Hypothetical examples (96% efficiency, 50-claim document) appear in data tables alongside measured values.

Why it matters: Examples become cited as data. "~96% reduction" migrates from illustrative to factual.

Fix: Keep illustrative examples OUT of data tables. Use separate "Examples" sections.

6. THE STALENESS TRAP

Problem: "Verified: 2025-12-21" on rapidly-changing claims (competitor features, pricing, URLs).

Why it matters: A URL verified yesterday may 404 today. External claims have different shelf lives.

Fix: Add staleness markers:

• [STABLE] -- historical facts, standards, completed events
• [CHECK BEFORE CITING] -- competitor features, pricing, team info
• [VOLATILE -- verify before use] -- URLs, API endpoints, market data
• [SNAPSHOT -- [date] only] -- stock prices, user counts, rankings

7. THE TEMPORAL INCOHERENCE TRAP

Problem: Document dates are wrong at creation time — not stale, just incorrect.

Why it matters: A document claiming "Last Updated: December 2024" when created in December 2025 will mislead any reader or LLM about temporal context. Unlike staleness (claims that decay), this is an error at creation.

Sub-checks:

1. Document date vs current date: Is "Last Updated" correct? In future? Suspiciously old?
2. Internal chronology: Are version numbers, changelog entries, event dates in logical sequence?
3. Reference freshness: Do "current", "now", "today" claims have date qualifiers?

Fix:

• Verify "Last Updated" matches actual update date
• Check all dates are in chronological order
• Add "as of [date]" to time-sensitive claims
• Use future tense for planned items

Relationship to Mode 6 (Staleness):

• Mode 6 catches claims that WILL become stale (volatility)
• Mode 7 catches dates that are ALREADY wrong (incoherence)

8. THE UNVERIFIED SPECIFIC CLAIMS TRAP

Problem: Specific numbers (pricing, statistics, rates) included in Verified Data without actually verifying them.

**Why it matte