Let AI Teach Me · Three defenses

Have AI mark the five kinds of facts it's most likely to invent

In an answer that reads smoothly, five spots should be suspect by default. When you're done, you can point to where they are.

Four-panel comic: Alice copies a fluent AI answer, then the facts fall apart when she checks them on the spot

The smoother the answer, the easier it is to skip the check. Alice's numbers, dates, and API names only fail when she looks them up on site.

Friday afternoon. Alice has to hand a colleague an event plan the AI put together. It reads smoothly: expected participation is 47%, the new process goes live on June 1, data can be exported through syncRecords(), and the old appendix even mentions auto-restore across devices. Headings, bullets, the conclusion — all laid out complete.

She doesn't spot a grammar issue or a contradiction, so she drops it straight into the briefing. On the spot they open the original announcement and the help docs: the number, the date, and the API name aren't there, and the so-called auto-restore never shipped. A few concrete details drag the whole plan back into rework.

The problem isn't whether the answer sounds real. The move that actually saves time is locating the spots most worth checking first. Suspect means “needs evidence,” not “already wrong.”

Walk the check with Alice first
Alice
Alice
AI risk-check drill · Flags risk only — doesn't replace the original material
Online
An AI answer reads fluently. How do you plan to check it? All three habits are common, and each only covers part of the risk. Pick one first.
A more solid start: Pull the five high-risk facts out of the answer as-is, then find evidence for each one. That way a short feature claim with big consequences doesn't slip through just because the whole paragraph reads smoothly.
Now pick 3–5 snippets or check actions. Mixed in are three clues that look reliable but don't actually prove a fact.
0 selected, at least 3 more needed
Flag these five spots as suspect first, then decide the check order
  1. Numbers: Amounts, rates, thresholds, version numbers, and parameters down to the decimal.
  2. Timeline: Publish times, go-live dates, sequence, and update points.
  3. Settings or API names: Even if the name looks like the real product copy, go back to the actual UI or official docs.
  4. Obscure details: A line in an old manual, an attachment, or meeting notes — hard to cross-check from outside.
  5. Feature claims: Claims that it supports, can, or automatically does something — especially don't fill in the blank with common experience.

The five types are just risk labels. If the original stats table matches 47%, that claim stands. If the help page has no auto-restore, the feature claim is only then disproved by evidence. Flagging suspect is for the queue. Checking the original is for the verdict.

Spell out the check clearly
Copy this as-is
  1. Pull the five types out as-isFrom the answer below, extract numbers, timelines, settings or API names, obscure source details, and feature claims — as written. Don't rewrite. Don't judge whether the whole passage is reliable.
  2. Assign evidence to each oneOutput as “original sentence | category | original material to check | current status.” If there's no direct basis, write “needs check.” Don't invent page numbers or sources.
  3. Decide what to check first by consequencePoint out which error would change the decision, and give it the shortest check first. Clearly distinguish “suspect,” “confirmed,” and “disproved.”
Fluency is for the reading experience. Original evidence is what settles the facts.