How do you check an AI document before you send it?
A word count will not catch a placeholder name, a chart with no real data behind it, or a sentence that trails off mid-thought because the model ran out of context. Before you send an AI-made document, you need to know which faults are mechanical and catchable, and which ones only you can judge.
What actually goes wrong in an AI-made document?
Most problems fall into a handful of categories. The first is structural: a heading that promises a table, and then no table follows. A section that begins but does not conclude. A list that stops at two items when the heading said four. These are layout promises the model made and then forgot.
The second category is content that looks right but is not: a statistic with no source, a named person who does not exist, a date that contradicts the one two paragraphs earlier. The model is fluent, so these errors arrive in confident, grammatical sentences. That is what makes them dangerous.
The third category is residue: a placeholder that survived the draft stage ('INSERT CLIENT NAME HERE'), a filler phrase the model uses as punctuation ('it is worth noting that'), or a design choice — a purple gradient, an em-dash where a hyphen should be — that signals the page was assembled rather than written.
- Structural gap
- A heading, list or section that the document introduces but does not complete.
- Hallucinated detail
- A fact, name, date or statistic that sounds authoritative but has no source behind it.
- Residue
- A placeholder, filler phrase or stylistic tell that survived from the generation stage into the final draft.
- Consistency error
- A figure, name or claim that contradicts another instance of itself elsewhere in the same document.
Which faults can a machine catch reliably?
Some problems are mechanical and therefore countable. An em-dash in running copy is either there or it is not. A placeholder pattern — text in square brackets, or an ALL-CAPS phrase in the middle of a sentence — can be matched with a simple rule. Filler marketing verbs like 'leverage', 'unlock' or 'empower' appear as strings. A missing alt-text attribute on an image is absent or present. None of these require judgement; they require a scan.
Structural checks are also automatable up to a point. A tool can confirm that every heading promised in a table of contents has a corresponding section, that every figure has a caption, and that every internal cross-reference resolves. What it cannot confirm is whether the content of that section actually answers the question the heading posed.
| Fault type | Machine can catch? | What the check looks like |
|---|---|---|
| Placeholder text | Yes | Pattern match on brackets, ALL-CAPS tokens, known filler strings |
| Filler marketing verbs | Yes | Word-list scan against a curated blocklist |
| Missing section promised by heading | Partially | Heading-to-content mapping; cannot judge if content is adequate |
| Hallucinated statistic | No | Requires external verification against a source |
| Tone mismatch for the audience | No | Requires human judgement about context and relationship |
What still needs your eyes, and why?
Hallucinated facts are the hardest class of problem because the machine that generated them cannot reliably detect them. A separate model can flag low-confidence claims, but it will miss confident errors — and confident errors are the ones that reach the recipient unchallenged. You need to verify any specific claim you did not supply yourself: a figure, a name, a legal reference, a product specification.
Tone is the other thing a machine cannot judge on your behalf. A document that is technically correct can still be wrong for the relationship. Too formal for a long-standing client, too casual for a regulator, too hedged for a board that wants a recommendation. Only you know what that relationship requires.
A practical approach is to let automated checks handle the mechanical layer — placeholders, filler words, structural gaps, design tells — and reserve your reading time for the claims and the register. That is a division of labour, not a delegation of responsibility.
Does the tool that built the document help with checking it?
Sometimes, but with a caveat. A tool that generated the document is working from the same model that produced the errors. Asking it to self-check is asking the same system to catch its own blind spots. It will catch some things — it can re-read for consistency, flag its own low-confidence passages, and apply a rule list — but it is structurally unlikely to catch the class of error it is most prone to making.
GROX applies a rulebook to every build it produces, counting the measurable tells of AI-generated pages — em-dashes in copy, filler marketing verbs, placeholder names, stock purple gradients — as counted facts alongside other checks, rather than as a model's opinion. That is useful for the mechanical layer. It does not replace reading the document for truth.
A simpler tool — a word processor's find-and-replace, a custom script, a checklist you run yourself — is often the better choice for the mechanical layer precisely because it is transparent. You can see exactly what it checked and what it did not.
Common questions
Can I ask the AI that wrote my document to proofread it?
You can, and it will catch some things: repeated words, broken sentences, inconsistent capitalisation. But the model that generated the document shares the same blind spots that produced its errors. It is structurally unlikely to flag a hallucinated statistic it stated confidently, or a tone that is wrong for your specific reader. Use it for surface-level checks; verify claims yourself.
How do you spot a placeholder that survived into a final draft?
Search for square brackets, angle brackets, and ALL-CAPS strings longer than three characters. Also search for known filler phrases your template uses, such as 'INSERT NAME' or 'TBD'. A plain text find is faster and more reliable than reading through the document hoping to notice them. Run it before you read, not after.
How do I check whether a statistic in an AI document is real?
Treat every specific figure as unverified until you have traced it to a primary source — the original study, the official release, the filing. A secondary source citing the same figure is not sufficient, because AI-generated text often invents figures that then circulate as citations. If you cannot find the primary source, remove the figure or replace it with a claim you can support.
Are there faults that look fine on screen but break when the document is printed or exported?
Yes. Text that overflows its box in a PDF, a chart that renders as a grey rectangle when the embedded data is missing, a font that substitutes on a system that does not have it installed, a table that splits across a page break in a way that hides the header row. These are layout faults that only appear at output. Always export and open the final format before sending, not just the authoring view.
GROX counts the measurable tells of AI-generated content — placeholders, filler verbs, design patterns — as part of its site and build checks; see what it covers at grox.life.