Trust and limits
A model's errors come from four places, and knowing which one tells you where to look. You decide how far to trust a model one task at a time, then draft, check, revise and sign.
Where the errors come from
An error in a model's output is rarely random. It comes from one of four places, and knowing which one tells you where to look.
| Kind of error | What it looks like | Why it happens |
|---|---|---|
| Invented fact | A plausible instruction number, statistic, quotation or name that does not exist | The model continues text the way real text continues; nothing checks the claim |
| Wrong number | A total, date difference or count that is close but wrong | It predicts the shape of an answer rather than computing it |
| Misread source | A summary that attributes to your document something the document does not say | A long or badly scanned file, or a question whose answer is not in the file, so it fills the gap |
| Right reasoning, wrong premise | A careful, well-argued answer built on a fact you or it got wrong at the start | It does not question what it is given; a confident premise is treated as true |
The fourth kind catches experienced users. A reasoning mode makes the chain of reasoning more careful; it does not check the starting point. If the first fact is wrong, the model reasons neatly to a wrong conclusion and shows its work.
How to treat it
| Treat it as… | Do not treat it as… |
|---|---|
| A drafting aid | A finished answer to send unread |
| A place to work from sources | A replacement for opening those sources |
| A helper for comparing options | The person who makes your decision |
| A tool within your workflow | Approval to skip your review |
What "good at" means in practice
The model's strength is proportional to how much of the answer is already in the request. That gives you a scale for how much checking a task needs.
| Task | What the model is doing | Check it needs |
|---|---|---|
| Rewrite, reformat, change tone | Rearranging text you gave it | Read it once; look for dropped content |
| Summarize a document you attached | Compressing text you gave it | Compare against the document for anything added or lost |
| Extract names, dates, items into a table | Locating text you gave it | Spot-check rows against the source; count the rows |
| Compare options against criteria | Reasoning over your material, plus its own judgment | Check every factual claim; treat the judgment as a colleague's opinion |
| Answer a question from its own knowledge | Guessing from training data | Verify every claim independently, or do not use it this way |
| Arithmetic, day counts, totals | Predicting digits | Recompute, or make it use a code tool and read the code |
Most staff work sits in the top half of that table, which is why the tool is worth your time. The bottom half is where people get burned.
Useful work to start with
- Document reviews
- Briefing preparation
- Meeting action items
- Project checklists
These are illustrative task categories, not a model ranking.
Source: Google, Gemini Gems overview (checked 25 Sep 2026).
Work in rounds
The model gives you the most plausible reading of what you sent, and your first request never contains everything it needed. Your format, your reader, the fact that item 3 is out of date: it cannot know these until you say them, and you usually only notice what you left out when you see the draft. Each correction adds what the first request lacked, so the second draft is built on more than the first. That is not a fault in the tool; it is what working with a language model looks like.
The reliable way to work is in rounds. Two or three rounds is normal, and each takes a minute. What does not work is the single prompt, the unread output, and the surprise a week later.
- Ask for a draft
- Read it against the source
- Correct specifically
- Read the revision
- Decide
"Item 3 is not in the instruction; the date in paragraph 2 should be 14 March; the tone is too informal for the CO."
The corrections you give are the most valuable text in the conversation. They tell the model what "right" looks like for you. If you give the same correction every time, put it in a project instruction or a custom assistant and stop repeating it.
Five pitfalls and what to do
| Pitfall | What to do |
|---|---|
| Fire-and-forget work | Work iteratively. Review the draft, give corrections, check the revision. |
| No source supplied | Attach the relevant source; ask it to mark anything the source does not establish. |
| Citations accepted unread | Open each citation and confirm it supports the sentence. |
| Numbers accepted unchecked | Compare with the source table and recompute the arithmetic. |
| "Done" accepted without inspection | Read the output against your requirements before signing. |
How to verify without reading everything twice
Verification scales with consequence. A draft email to your own division gets one read. A memo the CO signs gets the source open beside it. A number in a brief gets recomputed. Three habits make this fast.
| Habit | Ask | What you get |
|---|---|---|
| Claims first | "List every factual claim in this draft and where it comes from." | A list that is quicker to check than the prose; the claims with no source are the ones to chase |
| Mark the gaps | "Mark anything you could not establish from the source." | "[not in source]" beside two sentences, which tells you where to look |
| A fresh critic | In a new chat: "Here is a draft and its source; list every claim the source does not support." | Cheap insurance; it is not proof |
A staff example
| What happened | The fix |
|---|---|
| A leading petty officer asks for a summary of a new message on uniform changes, attaching the message. The draft is good but includes an effective date that is not in the message; the model borrowed it from an older policy it saw in training. | The correction "the effective date is not in the message; say so rather than supplying one" fixes the draft. Added to the division's project instructions, it stops the same error next month. |
What to do with this
Pick one document you produced this week with the tool and ask a fresh chat to list its claims against the source. Then read What you are actually sending, which explains why the model's behavior depends on far more than the words you typed.
Vendor facts checked ; re-verify before relying on them.