Fact Check

Step 2: Route Each Claim to Verification Source

Use this keyword-based routing table. Order = specificity (most-specific keywords first). When a claim matches multiple rows, try all matching sources in parallel up to the 3-source cap.

Fallback chain: primary source then web search then unverified

Step 3: Verify Independently

For each claim + source pair, actually check the source.

Local Codebase (Deep Read)

CRITICAL: For claims about our own architecture (Sven, the daemon, the bus, sessions, skills, manager, watchdog, poller, signal integration, etc.), a shallow grep is NOT sufficient. You must deeply read the actual implementation code to verify, not just find a keyword match.

Process:

1. Grep to locate — find the relevant files:

   Grep(pattern="relevant search terms", path="~/dispatch/")
   Grep(pattern="relevant search terms", path="~/.claude/skills/")
   

2. Read the actual code — open matching files and read the surrounding implementation (50-100 lines of context). Understand what the code actually does, not just that a keyword appears.
3. Trace the logic — if the claim is about behavior ("the daemon does X when Y"), read the actual control flow. Follow function calls if needed. A keyword match in a comment doesn't count — verify the runtime behavior.
4. Check CLAUDE.md docs — also read ~/dispatch/CLAUDE.md and ~/.claude/CLAUDE.md for documented architecture, but always cross-reference with actual code (docs can be stale).

Target specific directories — never broad-scan. Key locations:

• ~/dispatch/ — daemon, manager, bus, sessions, watchdog
• ~/.claude/skills/ — all skill implementations
• ~/dispatch/bus/ — bus producer, consumer, search
• ~/dispatch/state/ — session state, bus.db

Bus Database (FTS)

import sqlite3
conn = sqlite3.connect(os.path.expanduser('~/dispatch/state/bus.db'))
# For conversation history:
results = conn.execute(
    "SELECT timestamp, topic, type, payload FROM records_fts WHERE records_fts MATCH ? ORDER BY rank LIMIT 5",
    ('search terms',)
).fetchall()
# For tool calls/results:
results = conn.execute(
    "SELECT timestamp, session_name, event_type, tool_name, payload FROM sdk_events_fts WHERE sdk_events_fts MATCH ? ORDER BY rank LIMIT 5",
    ('search terms',)
).fetchall()

Empty results = unverified. Malformed query / exception = catch, mark unverified with error reason.

APIs / CLIs

Call the specific CLI from the routing table. Examples:

• Hue: use /hue skill scripts to query bridge state
• Flight: use /flight-tracker skill scripts
• Reminders: use /reminders skill scripts
• Sonos: use /sonos skill scripts

10-second timeout per call. Exception = unverified with error reason.

Web

Use the built-in WebSearch tool (native Claude Code tool) to search for the claim. Check up to 3 results. Use WebFetch (native Claude Code tool) for specific URLs — official docs, pricing pages, GitHub READMEs.

Code Verification (Independent Re-Implementation)

For claims that a function, script, or computation produces a specific numeric or structured output, verify by independently re-implementing the computation — never re-run the original code.

Process:

1. Identify the computation — what is being computed, what are the inputs?
2. Write a fresh implementation — do NOT copy or re-run the original code. Write an independent implementation from scratch using first principles or a different approach.
3. Run it via uv run with appropriate inline deps:

   # /// script
   # dependencies = ["numpy"]
   # ///
   import numpy as np
   # ... fresh implementation ...
   

4. Compare outputs — use appropriate tolerance:
   • Floats: ±0.01 (or domain-appropriate precision)
   • Integers: exact match
   • Strings: exact match
5. Verdict:
   • Within tolerance → verified
   • Outside tolerance → wrong (report both values)
   • Can't reproduce inputs → unverified with reason

NEVER: re-run the original script to verify itself. That proves nothing. Always use an independent approach.

Verification Rules

• NEVER use LLM knowledge — only what external sources return
• Partial match = quote source verbatim, flag the mismatch. Don't interpolate.
• Contradictory sources = report both verbatim, don't pick a winner
• Source text neither confirms nor denies = inconclusive, not verified

Step 4: Verdict + Output

Five verdict categories:

Key distinction:

• Inconclusive = "found something related but doesn't directly address the claim"
• Unverified = "found nothing" or "source failed/timed out"

Output Format

## fact-check results
checked N claims in Xs

1. [verified] "signal-cli supports JSON-RPC"
   source: signal-cli README.md
   > "signal-cli can run in JSON-RPC mode..."

2. [wrong] "API costs $5/month"
   source: pricing page (fetched YYYY-MM-DD)
   > actual: "$10/month for pro tier"

3. [inconclusive] "the poller handles reconnection"
   source: ~/dispatch/poller.py (lines 42-50)
   > mentions reconnection in a different context

4. [unverified] "you mentioned this last week"
   source: bus.db records_fts — no matching records

5. [unverifiable] "my friend recommended it"
   personal anecdote — can't independently verify