Fact-Checking AI Text: Hallucination Checklist

The only dependable way to catch a hallucination before it goes live is to treat the AI output as a draft and check every verifiable claim by hand. Google's page on generative AI content (Opens in a new tab) says exactly that: AI output can contain errors, and manually fact-checking and reviewing all of it is critical. If you run a board game review site, the draft in front of you might be a party game, a heavy strategy title or a piece on a classic from another country, and the question for each sentence stays the same. Can I tie it to a source, or to a table I played at myself?

This list is for the publisher's own editorial desk. A buyer checking text delivered by a writing service has a different vantage point, which the editor review checklist for AI-assisted writing services covers. Here the work happens before the review is published under your name.

What the model does when it writes a review

Google's document explains that generative models do not retrieve facts. They predict a likely sequence of words from their training data. In a board game review, a likely sequence of words looks like a plausible player count, a plausible play time and a plausible rule. Plausible is not the same as played.

Fluent text hides the weak spot

A sentence such as "each round ends when the last card is drawn" reads smoothly whether or not the rulebook says so. The reader finds the problem at the table, when the group argues over a rule. Practical suggestion: read the draft for the parts that can be checked, not for the parts that sound right. Every number, component name, rule and time is a checkpoint.

Gaps get filled

If your prompt omits a detail, the tool may supply one. Give it a title and a list of components, and it may invent the number of rounds or the box contents. Feed the tool only what you have played and measured. When the draft contains a detail you did not provide, treat it as unverified until you can source it or test it.

The same prompt does not return the same review

Running a prompt twice can produce different player counts. That makes reliance on past accuracy a weak control. Verification attaches to the claim in front of you, not to the tool's track record.

Narrowing the prompt lowers the risk without removing it

Practical suggestion: give the tool only notes you have taken at the table and add an instruction not to supply anything you did not provide. That can reduce invented detail, but it does not eliminate it. If the draft shows a play time, an expansion name or a designer that was not in your prompt, treat it as a red flag and remove it unless you can source it.

Phrases that mark a sentence for checking

Certain patterns tell the editor where to look first: absolute claims such as "the original edition", "the only way to win" or "award-winning", named places and people, years in brackets, percentages, and soft supports like "it is said". None of these proves an error. They only decide which sentence is checked before the others.

A taxonomy of review errors

Different mistakes are hunted in different places. The grouping is for a review desk. The grouping is a working aid and not a claim from any source document.

Safety errors rank first

Practical suggestion: sort errors by what the reader might suffer. A slightly wrong play time is a disappointment. A wrong age recommendation for a game with small pieces can put a young child at risk. Safety-relevant statements deserve a source from the publisher's own labelling and a second pair of eyes.

Player counts, play times and rules

These are the checkpoints the model gets wrong easily and an editor can test. A rulebook is an instruction set, so a single wrong value breaks the review.

Player counts and ratios

Compare the player range, the recommended count and the component totals with the box and the rulebook. If the AI draft departs from the printed range, ask why. Sometimes the answer is a legitimate variant, sometimes a slip. A review of a base game and its expansion is another trap, because a tool can credit the expansion's rules to the base game. Recheck each line.

Play times and rounds

Check the printed play time against what your own sessions took, and state both when they differ. Times should come with a context, such as a first game with new players, so that the clock is not the only guide. Verify each time by actually playing the game.

Terms and conversions

List every term the draft uses for the same thing. Look for mixed names inside one review and for abbreviations that can be misread. When a game has a local title and an English title, write the one on the box you hold and convert nothing from memory.

Component names, variants and edition notes

Component names vary by edition and by language, and a model may use the name from a different printing, which confuses readers elsewhere. Check each name against the edition your audience can buy. Variants deserve a test: swapping a card deck for another or playing without an expansion changes the experience, and a tool will happily claim that it does not.

Accessibility and age labels

A note such as "colour-blind friendly" or "suitable from age eight" is a factual claim about every component in the box. A tool may describe a card or a token without noticing what is printed on it. Practical suggestion: before such a label goes live, check each component yourself and keep the claim off the page if you cannot confirm it.

Names of mechanics and designers

If the draft says a mechanic was invented by a person or in a place, verify the claim from a designer interview or a publisher page before you repeat it. A model can produce a design-history claim with confidence and no basis.

Photographs and captions

The picture is also a claim. A photograph shown as the game in play must be of the edition you describe, set up by your team. A generated image of a table that looks perfect sets an expectation the game cannot meet. If a stock or generated image is used for atmosphere, say so in the caption and keep it apart from the components. The caption should name what is pictured and match the component list.

Price, award and history claims

Claims about price, awards, sales figures or the history of a game are factual statements that need a source, even when they sit in a single line. A model asked for award information may return a year and a jury name that look exact. Only a check against the award body's own list, or a cited reference, makes the statement usable.

• Award and price statements come from the awarding body or the publisher, never from the tool alone.
• Sales and popularity claims are attributed to a source or removed.
• Historical statements name the source they rest on.
• Where evidence is thin, the sentence is softened to match it or deleted.

Equipment and setup statements

Statements about equipment ("a large table is required", "sleeved cards shuffle better") sound like facts but can be preferences. Check each one by asking whether the result changes without it. If it does not, rewrite the sentence as a suggestion. If it does, say what changes.

Invented sources and dead links

A model can name a rulebook that was never printed, or give an address that looks right and leads nowhere. That follows from how it generates text. Each source it supplies is opened before you use it.

Link check sequence

1. Open the link and confirm the page exists.
2. Check who published it and when.
3. Find the claim on that page. A real page does not prove that it says what the draft says.
4. If the link redirects, use the final address.
5. Note whether the source is primary or secondary.

A source that cannot be opened is dropped. If nothing else supports the sentence, the sentence goes too. The guide to citing sources and attribution explains how to present the references that survive.

Cross-checking against more than one source

The IFCN's code of principles (Opens in a new tab) is written for organisations that publish fact-checks, so it does not govern a game review site. Read as a general principle, however, it offers a useful pattern: use primary sources where suitable ones exist, explain reliance on secondary sources, and check the key elements of a claim against more than one named source. It also asks signatories to disclose source interests that could affect the evidence.

Applied to game coverage

Practical suggestion: for a claim with consequences, such as an age label or the origin of a disputed design, look for two independent sources. The rulebook and the publisher count as primary. A blog repeating the claim is secondary and says nothing more than its own source did. A source with something to sell, such as a publisher praising its own title, is noted as such in the text.

Updating old reviews

A model asked to refresh an old post may alter player counts, merge rule descriptions or change component names while rewriting the prose. Compare the refreshed version with the published one line by line, not by reading it fresh. Anything that changed must be traceable to a reason you can state, such as a new edition or a new session.

Titles, meta text, schema and alt text

Google's page applies the same manual review to title tags, meta descriptions, structured data and image alt text, since these can appear in search results. It also says structured data should follow Google's general and feature-specific guidelines and be validated.

Short fields conceal errors

A title promising "a game for two in 20 minutes" must match the rulebook and the timings in the body. A meta description that names a mechanic must match the review text. Compare every fact in these short fields with the full text.

Review markup and alt text

If your pages carry structured data for reviews, the values in it, such as the rated item, the author and the rating, must equal what is on the page. Run the markup through a validator. Alt text describing a photograph should describe the components as pictured, not the box as the tool imagines it.

Playing the game: the check no tool replaces

Documents can confirm a fact, but only a session confirms a review. First-hand play is also the strongest signal that the content reflects real experience. Practical suggestion: no review produced with AI help is published until someone has played the game as the rulebook describes it.

What the session records

• The edition, player count and components used.
• The play time and the table size observed.
• Rules that were unclear, written back into the review.
• A photograph of the game actually played, not a generated image.

When playing is not possible

For a roundup or a history piece where play is not the point, the equivalent is source checking. For a review, if you cannot play the game, do not publish it as your own review.

Publishing under convention-season pressure

Review sites live on release calendars. A review has to be live when a big title ships or a convention opens, and the deadline pushes editors to skip the extra session. Define in advance what may be dropped under pressure and what may not.

Practical suggestion: remove what you cannot verify and add it later. Publishing a short, correct review is better than a complete one with a doubtful rule.

Three stages of review

Practical suggestion: a small desk can run three stages.

1. First read: the person who prepared the draft marks the claims that need checking.
2. Verification: a second person, or the same person later, matches each marked claim to a source or session and fills the log.
3. Final approval: the approving editor checks the log and the flow of the text, and does not reopen every source.

An empty log line stops publication.

Sign-off, the verification log and corrections

If nobody writes down what was checked, the next editor repeats the work or, worse, assumes it was done. Keep a short log per piece in a shared workspace, not inside the page.

Log fields

• Claim or value checked.
• Source or session used.
• Result: confirmed, corrected or removed.
• Name of the person who checked.
• Date.

Who signs

The person who approves publication answers for the text, whichever tool wrote the first draft. The sign-off line carries a name, not a tool. The wider editorial framework is set out in AI-written articles and human editing.

Corrections

The IFCN commitments ask signatories to publish a corrections policy and follow it, and to correct clearly and transparently. As a general principle it suits any publisher. A review found to be wrong is not quietly edited. A correction note says what changed and when, and where the error could have harmed someone, it appears prominently. Record in the internal log how the error got through, and add a check to the list for that stage.

Planning how much checking a claim gets

The time given to a check should match what is at stake. A remark about the box art needs a quick look. An age recommendation, a statement about small parts or a claim about a named designer or publisher needs far more. Write this proportion down in advance so that a busy day does not force the desk to improvise.

• Low stakes: player counts, component names, titles.
• Medium stakes: attributed history, award statements, quoted sources.
• High stakes: age and safety labels, accessibility claims, statements about named people or companies. These get a second reviewer.

Decision rule: publish, fix or hold

Use this table when the draft reaches the final reviewer.

Worked example: a board game review site

Example scenario: the editor of a board game review site asks an AI tool for a draft on a two-hour cooperative strategy game. The draft includes a rules summary, a short story about the designer, a line on an award and a link to a design article.

What the desk does

1. The game is played as the rulebook describes. The draft states a turn order the rulebook does not use, so the summary is corrected and the change written into the review.
2. The designer story names a city. No interview or publisher page mentions it, so the sentence is removed.
3. The article link opens a real site, but the page does not contain the claim attached to it. The claim is dropped.
4. The award line is replaced by the entry on the award body's own list.
5. The title promises a short play time. The session shows a longer first game, so the title is changed.
6. The log is completed and the editor's name goes on the sign-off line.

The tool saved the time of drafting. The checks that make the review trustworthy stayed with the editor.

A second example: refreshing an older review

Example scenario: an editor asks the tool to update a review of a family game after a new edition. The new draft changes the age recommendation and adds a note that the pieces are safe for toddlers. The editor checks the new box, finds the age label unchanged, and restores the printed one. The toddler note has no source, so it is removed and replaced with the age grade printed on the box. The refreshed post now carries an updated date and a short note on what changed.

The mistake was not a wild invention. It was a plausible change that nothing had supported, which is the kind of error a reading pass alone misses.

Misreadings

"The tool cited a source, so it must be right"

The source must exist and must contain the claim. Both are checked by you.

"A second AI tool can verify the first"

Two tools can repeat the same error. Compare the text with the source pages, not with another model.

"A small error does not matter in a review"

A small error in a player count or a rule changes how the game is judged, and an error in a safety statement changes more than that.

"If I fact-check, I need no disclosure note"

Verification and disclosure are separate decisions. Your publication policy settles the second one. The first is always done.

For a broader view of what makes an article helpful, see the helpful content guidelines and article quality scoring table.

Final checklist

• The game was played as the rulebook describes and the review corrected from the session.
• Player counts, play times, rules and component names were checked.
• Component and edition names suit the audience and variants were tried.
• Age and accessibility labels were confirmed component by component.
• Price, award and history claims have sources or were removed.
• Every link from the tool was opened and the claim was found on the page.
• Title, meta description, markup and alt text match the body.
• Safety-relevant statements rest on the publisher's labelling.
• The verification log is filled and signed by a named person.
• A correction path is ready.

The Turkish-language editing and consistency check guide applies the same habit of consistency to spelling and units.

Weekly review questions

At the end of each week the desk can ask:

• Did the number of post-publication corrections rise?
• Which kind of error caused them: number, name, quote or link?
• Was the quick-publish check applied, or were pieces published without it?
• Were the log lines filled and signed?

The questions are about finding weak points in the process, not blaming people. An answer that turns into a new line on the checklist means the review is doing its job.

Frequently Asked Questions

Why can AI output be wrong?

According to Google's document, generative models do not retrieve facts but predict a likely sequence of words, so fluent text can still be wrong.

Who should check AI text before publication?

The editor who approves publication answers for it. Someone else can do the checking, but the sign-off carries a person's name.

Can I trust the references an AI tool gives me?

Not until you open each link, check the publisher and date, and find the claim on the page. A source that cannot be opened is not relied on.

Do titles and meta descriptions need checking too?

Yes. Google's page says title tags, meta descriptions, structured data and alt text deserve the same manual review.

What can be skipped under time pressure?

Fact verification cannot be skipped. Remove what you cannot verify and add it after checking.

What should I do if a published review turns out to be wrong?

Do not edit it silently. Add a correction note saying what changed and when, and record internally how the error passed review.

Conclusion

An AI draft is a starting point. Player counts, play times, rules, component names, labels, sources and the claims in titles and markup all need to be matched to evidence, and the game itself needs to be played. Separate the kinds of error, set a short check for release-calendar deadlines, keep a log and make corrections visible.

If you would like an editor-supervised workflow for your articles, the content writing service page lists the options.