Verified against Gemini · 2026-08-02
Verify every checkable claim in a draft against live search results before it ships
A grounding-focused prompt that has Gemini check each factual claim in a draft against current web sources — not just its own training knowledge — and label every claim by how well it held up, using the kind of source-backed verification Gemini's search-grounded response checking is built for.
The prompt
Ready to copy — highlighted parts are example details you can swap.
Fact-check the draft below against live search results, not just what you already know from training. Treat your own training knowledge as a starting hypothesis to verify, not as the answer. DRAFT a 900-word blog post draft claiming specific market-size and growth-rate figures for the AI code-assistant market WHAT COUNTS AS A CHECKABLE CLAIM numeric statistics, named product/company claims, and any date-specific event mentioned WHAT NOT TO TRY TO VERIFY the author's own opinions and predictions — those aren't checkable facts, don't try to verify them against a source INSTRUCTIONS 1. Go through the draft and pull out every checkable claim as its own item — don't fact-check the draft as one undifferentiated block of text. 2. For each claim, search for and cite a current source, then compare the draft's version of the claim against what that source actually says — not against a rough impression of the topic. 3. prioritize sources published within the last 12 months for anything about current market size 4. Where a claim is close but not exact — a number stated as 22% when the best current source says 19% — say so precisely rather than rounding the discrepancy away or calling it either fully right or fully wrong. 5. If you cannot find a source that speaks to a claim at all, say that plainly. A claim you couldn't verify is a different and more useful finding than one you assume is probably fine because it sounds unremarkable. LABELING SCHEME Label every claim as one of: Confirmed / Partially supported / Contradicted / Could not verify MULTIPLE SOURCES DISAGREEING WITH EACH OTHER If you find current sources that disagree with each other on a claim, not just with the draft, report both and let the "Contradicted" or "Partially supported" label reflect that the evidence itself is mixed, rather than picking whichever source happens to agree with the draft and calling it confirmed. CLAIMS THAT ARE TECHNICALLY TRUE BUT MISLEADING IN CONTEXT If a claim is technically accurate on its own but framed in the draft in a way that implies something broader or different than the source actually supports (a real statistic used to imply a trend the source doesn't establish), flag that separately from a simple true/false check — note what the source actually supports versus what the draft's framing implies a reader would take away. IF A CLAIM HAS ALREADY BEEN UPDATED OR RETRACTED If your search turns up a more recent correction, update, or retraction of a source the draft appears to be relying on, surface that explicitly and prominently — a claim built on evidence that has since been walked back by its own original source is a materially different situation than a claim that is simply unverifiable. OUTPUT FORMAT A table: claim (quoted from the draft) | label | source cited | what the source actually says, if it differs from the draft's version. Follow it with a short section on any claims flagged as technically true but misleadingly framed. End with a one-line summary of how many claims fell into each label.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Grounding a check against live search results catches a specific and common error mode that pure training-knowledge recall cannot: a plausible, fluent claim that was true at some point, or true of a different but similar entity, but isn't actually verifiable against a current source — this is different from and complements the model's own training knowledge, which is fixed as of a cutoff date and can be stale by the time the claim is actually being checked. Distinguishing checkable claims (a number, a date, a named entity) from unhackable ones (an opinion, a prediction) up front stops the verification pass from either skipping real factual claims buried in the text or wasting effort trying to 'fact-check' a subjective statement that has no ground truth to check against in the first place, which would just produce a nonsensical label on something that was never a factual claim. A four-way confidence label, rather than a binary true/false, matches how source verification actually plays out in practice — many claims are close but not exact, and forcing a binary label on that either overstates the problem by calling a near-miss false, or understates it by calling an imprecise figure true, when the useful information is the size and direction of the gap. The recency requirement matters specifically for anything time-sensitive: a technically accurate but two-year-old market-size figure verified against an equally old source will look 'confirmed' on a literal reading while actually being outdated for the draft's current claim, which is a worse outcome than an honest 'could not verify a current figure' that at least tells the writer where to dig further before publishing. Separating a technically-true-but-misleadingly-framed claim from a straightforward false one matters because these need different fixes entirely — a false claim needs correcting, while a true-but-misleading one needs re-framing, and collapsing both into the same 'confirmed' or 'contradicted' label would either wrongly clear a claim that's doing real rhetorical damage to the reader's takeaway, or wrongly flag a claim whose underlying fact is genuinely accurate and doesn't need a correction at all, just a softer framing around it.
What you get back
"the global AI code-assistant market is projected to reach $12B by 2027" | Partially supported | [industry analyst report, published 2026-03] | the cited report projects $9.8B by 2027, not $12B — the draft's figure appears to combine two different market segments the source keeps separate. "GitHub Copilot was the first AI pair-programming tool" | Contradicted | [product history article, 2024] | earlier tools (e.g., Kite, TabNine) predate Copilot's 2021 launch; the draft's claim doesn't hold as stated.
Verified against
Gemini Gemini 3 Pro · 2026-08-02
Changelog
- 2026-08-02 — Initial publish, verified against Gemini 3 Pro grounding-checking a 900-word draft with market-size claims.
Need this built into your business?
If a prompt isn't enough — what Scult builds, built and maintained for you — that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
