fact-check

Fact-Check

Turn a claim or research question into a sourced, reproducible verdict with a predictable shape. The goal is not to sound confident — it is to show the work so a reader can trust (or re-run) the conclusion.

Core principles

• Evidence over assertion. Every verdict must trace to a source you actually retrieved, a page you actually loaded, or code you actually ran. Never rely on memory for a fact that a tool can confirm.
• Prefer primary sources. Official docs, specs, standards bodies, the vendor's own site, the paper itself, the law's text — over blogs, forums, or aggregators. Note the tier of each source.
• Corroborate. A single source is a lead, not a conclusion. Seek at least two independent sources for a non-trivial claim; note when you could only find one.
• Separate claim from framing. Restate the claim precisely before judging it. Split a compound claim into its parts and check each — the parts can have different verdicts.
• Report uncertainty honestly. "Unverifiable" is a valid, useful verdict. Do not round a weak result up to "True".
• Date everything. Facts expire. Record the date checked and each source's date.

Verification methods

Pick the cheapest method that can actually settle the claim; escalate as needed.

1. Web search (web) — find candidate sources, current figures, definitions, dates, official statements. Start here for most claims. Cross-check across independent hits.
2. Live browsing (playwright/*) — when the answer needs a page that search snippets don't fully capture: interactive dashboards, docs behind JS, current prices/status, forms, tables, or content that changed recently. Navigate, read the DOM, extract the exact figure, and capture the URL + what you saw.
3. Code execution (bash) — when the claim is computable or testable: math and unit conversions, statistics on a dataset, "does this API return X", "does this snippet compile/behave as claimed", regex/format checks, parsing a downloaded file. Write a small script, run it, and quote the output as evidence.

Combine methods freely. Use whatever additional resources the claim requires (download a CSV and analyze it, hit a public API, read a repo file). Keep each method's result attributable to a source line.

Workflow

1. Restate the claim/question precisely. Decompose compound claims into sub-claims.
2. Plan which method(s) can settle each part. Track multi-step checks with the todo tool when there are several sub-claims.
3. Gather evidence — run searches, load pages, execute code. Record each finding with its method and source as you go.
4. Weigh the evidence: source tier, independence, recency, and whether findings agree.
5. Judge each sub-claim, then the overall claim, using the verdict + confidence scales below.
6. Report using the output template. Never omit the sources.

Verdict scale

Choose the single best fit for the overall claim (and per sub-claim when decomposed):

Verdict	Meaning
True	Fully supported by strong, corroborated evidence.
Mostly True	Core claim holds; minor caveats, imprecision, or missing nuance.
Mixed	Partly true and partly false, or true only under specific conditions.
Mostly False	Core claim fails; only a small or incidental part holds.
False	Contradicted by strong, corroborated evidence.
Unverifiable	Evidence insufficient, inaccessible, or too conflicting to decide.

Confidence scale

Independent of the verdict — how sure are you of that verdict?

• High — multiple independent, primary/authoritative sources agree; or a decisive computation.
• Medium — good evidence with a minor gap, one strong source, or mild source conflict.
• Low — thin, indirect, dated, or single-source evidence; verdict is provisional.

Output template

Emit exactly this structure. For a single claim:

# Fact-Check: <one-line claim summary>

**Verdict:** <True | Mostly True | Mixed | Mostly False | False | Unverifiable>
**Confidence:** <High | Medium | Low>
**Date checked:** <YYYY-MM-DD>

## Claim
<The exact claim/question under evaluation, restated precisely.>

## Verdict rationale
<2–4 sentences: why this verdict, citing the decisive evidence.>

## Evidence
| # | Finding | Method | Source |
| - | ------- | ------ | ------ |
| 1 | <what you found> | <web / browser / code> | <[n] below> |
| 2 | ... | ... | ... |

## Method notes
<How you checked: key searches run, pages loaded (URLs), code executed + its output.
Enough detail that someone could reproduce the check.>

## Caveats & scope
<Assumptions, ambiguities, time-sensitivity, and what you did NOT check.>

## New findings & contradictions
<What the check surfaced that is new, surprising, or conflicts with a prior belief or an
existing wiki page. Name the specific contradiction and which source/page it clashes with.
Write "None — findings matched expectations." when there is nothing to flag.>

## Further questions
<2–5 genuinely interesting questions this raised — adjacent claims worth checking, deeper
"why", or where the evidence was thin. Each should be checkable, not rhetorical.>

## Sources
1. <Title> — <URL> (accessed <YYYY-MM-DD>, source tier: primary/secondary)
2. ...

For a compound claim, add a per-sub-claim breakdown before ## Sources:

## Sub-claims
| # | Sub-claim | Verdict | Confidence |
| - | --------- | ------- | ---------- |
| a | ... | ... | ... |

The overall Verdict/Confidence in the header then summarizes the sub-claims.

Publishing as a learning article

When asked to write up the research (a "learning blog", article, or analysis) — or when a fact-check is worth capturing durably — turn the verdict into a wiki analysis page so it plays well with the knowledge-wiki structure Dewey maintains. This is wiki work: follow the knowledge-wiki skill's analysis schema and page rules, and the wiki-only file constraint applies.

• Where it lives. wiki/analyses/<kebab-case-question>.md, type: analysis. Add a #fact-check tag alongside #analysis.
• Search first. Before writing, search existing wiki/ for related entities, summaries, concepts, or a prior analysis. Link to real pages; update an existing analysis rather than duplicating it. If a key source is new and important, also create a summary page for it and link the two.
• Article shape (analysis layout, written as an accessible learning explainer):
  • Lead — the research question and the verdict + confidence in 2–3 sentences.
  • ## Context — why the question matters and what prompted it.
  • ## What the evidence shows — the narrative walk-through: the reasoning, key figures, and how each was verified (link sources). This is the "learning blog" body — teach it.
  • ## New findings & contradictions — surface anything new or anything that contradicts an existing wiki page. When a wiki page is now wrong, either correct it (overwrite to reflect current understanding) or add an ## Open Questions entry there, and link it from here. Never leave a known contradiction unreconciled and unlinked.
  • ## Implications — what follows if the verdict holds.
  • ## Open Questions — the further questions from the check, as checkable prompts.
  • ## Related — the cited sources and every wiki page touched, with relative links.
• Provenance. Put summaries/raw it draws on in sources:, linked entities in entities:, and keep cross-links reciprocal. Add a log.md line (## [YYYY-MM-DD] fact-check | <question>) and run the wiki linter before finishing.

If the user only wants the answer, emit the report template and skip publishing. Standalone, offer the article as a follow-up when the topic is worth keeping; run by Dewey, publish it by default for any substantive question (skip only trivial checks).

Standalone use

This skill is self-contained: given only a claim or research question it produces the full report above with no other setup. When run standalone, print the report to the response by default and write it to a file only if the user names a path. When run by Dewey in fact-check mode, always print the report and — for any substantive research question — also capture it durably as a wiki analysis page in the knowledgebase (default ~/brain) per Publishing as a learning article above; skip publishing only for trivial or throwaway checks.