Every article on our insights page starts as an AI draft and ships only after a human review. The review is a fixed sequence: facts first, then voice, then structure, then links and metadata. Nothing goes live because it reads smoothly; it goes live because each claim was checked against a primary source, each heading answers a question a real person asked, and a person signed off on the result.
We run this process at Tigerless, where we build Lara inside a real insurance business, Tigerless Health, and publish our engineering work through Tigerless Labs. We make the tools mentioned in this article, and we will name where other approaches win. What follows is the review we actually run, step by step, so you can copy it.
How do you fact-check AI content before publishing?
Do the fact pass first, before you touch a single sentence for style. A polished hallucination is worse than a clumsy draft, because it is harder to catch.
We open the draft and highlight every sentence that names a number, a date, a price, a plan rule, a product capability, a company, a study, or a quote. Each highlight needs a primary source opened in a tab next to it: the official docs, the regulator, the vendor's own pricing page, the paper itself. If the source does not say what the draft says it says, the sentence goes. Google's own guidance on AI-generated content now says it directly: generative models predict likely word sequences rather than retrieving facts, so teams should manually fact-check everything, including metadata, before publishing — see Google Search Central's guidance on creating helpful content.
In practice our checklist for this gate is short:
Every statistic, deadline, eligibility condition, and price links the page where the claim was verified, at the sentence where the claim is made.
Every quote is checked word for word. AI drafts produce quote-shaped text that no one ever said; if we cannot find the original, we delete it.
Every product fact about our own work matches our product declaration. Lara reads plan documents, compares coverage, and explains enrollment, billing, and claims — she does not sell a policy, approve a claim, or give medical advice, and we never let a draft claim she does.
Dates get re-verified on the day of review. A price or plan window that was right when the draft was written is often wrong two weeks later, so we re-open each pricing and policy source before sign-off.
Two examples from our own site show why this gate comes first. Our walkthrough of seeing what Claude Code sends to the API and what each part costs prices tokens across fresh input, cache writes, cache reads, and output — every rate in that article links Anthropic's pricing and usage docs rather than quoting a figure from memory, because rates change. Our Design Harness launch article describes installation with the exact plugin commands from the repository, copied from the repo rather than recalled. When a draft's numbers cannot be re-verified, we soften or cut them: "is" becomes "can be," "always" becomes "often," and a precise figure becomes a billing shape with a link to the pricing page.
Anything that fails this gate blocks publication. Awkward phrasing can be fixed in line; a fabricated reference or an unverifiable product claim sends the draft back for a rewrite.
How do you catch AI hallucinations in citations and stats?
Look for the three places AI drafts invent specificity: references that do not exist, numbers that are too tidy, and attribution that is slightly off.
We check each citation in this order. Does the source exist at the URL given? Does the page contain the claim? Is the claim used within its original scope and date? A 2024 report cited for a 2026 rule fails the third question even when the first two pass. For papers we prefer the HTML or PDF itself — for example, an arXiv listing over a blog summary of it — and our paper-radar project exists precisely because affiliation and authorship are easy to misattribute from a secondary summary.
Stats get the same treatment. When a draft says a tool cuts cost by a named percent, we ask for the evaluation, its date, and its denominator. Our own cost-xray guide is careful on this point: per-call totals are calibrated to the provider's reported usage, while the split between sources inside one request is an estimate — and the article says so, because calling an estimate an invoice line would be a hallucination with better formatting. We hold AI drafts to the same standard: magnitudes and billing shapes in prose, exact figures only when the source states them, and the source linked where the figure appears.
The fastest tell is overconfidence. Drafts present situational advice as universal rules, drop the qualifications, and turn one user's report into "everyone agrees." Our editors restore the qualification first and ask whether the section still earns its place. If the only honest version of a paragraph is "it depends," that paragraph needs an example, a decision rule, or it gets cut.
How do you edit AI drafts without losing your voice?
Only after the facts clear do we edit for voice. Doing it earlier wastes work, because a sentence that sounds like us but says the wrong thing still has to go.
AI drafts default to a neutral, agreeable register: symmetrical headings, the same transition at every turn, generic encouragement at the end of each section. We strip that layer and replace it with how our team actually writes — direct, plain sentences, addressed to one reader with one question. Three passes do most of the work.
First, the openings. AI introductions warm up for two paragraphs before saying anything. We cut the warm-up and answer the reader's main question in the first paragraph. Compare the opening of our cost-xray breakdown, which states in two sentences what /usage shows and what only request capture shows, with a generic "in today's fast-moving landscape" opener. The former keeps the reader; the latter could open any article on any site, so it opens none of ours.
Second, repetition. AI drafts restate the same idea in adjacent paragraphs with different words. We merge them until each section holds one idea, then check sentence rhythm by reading aloud — uniform sentence length and repeated openings are the most reliable surface tell, and varying them usually fixes the "AI feel" without any other change.
Third, the human contribution. We ask what a person added that the model could not have supplied from pattern alone: a framework from real publishing experience, an honest limitation, a worked example, a sharper edge case. Our Design Harness article earns its length this way — the comparison of Design Harness against asking a model directly and writing by hand comes from dogfooding the tool on roughly 80 sources, not from rearranging feature lists. If a draft has no such contribution after the voice pass, it is not ready; it needs reporting, not more adjectives.
How do you check if headings match what readers actually ask?
Headings are promises, so we verify each one against a real question in the asker's own words.
Before review we search the topic the way a reader would: web search, Reddit threads, forum Q&A, product communities. Each H2 in the finished article should trace to one of those questions, quoted as asked — typos cleaned, wording kept. Our published guides follow this rule visibly: the cost-xray guide's headings are literal reader questions such as how to check usage and whether the capture sends traffic anywhere, and the Design Harness guide's headings are the install and sharing questions people actually type.
The review itself is mechanical. For each H2 we ask: is this a question someone asked, or a label we invented? Does the first paragraph under it answer that question directly, in a sentence or two, before any background? Can that section stand alone if an answer engine lifts it? A section that needs the rest of the article to make sense gets rewritten until it does not. We also confirm the table of contents reads as a set of distinct questions with no overlaps — two headings one reader would be served by one section become one section.
Internal links are checked at the same time. Every link must point at a live page on our own site — an insights article, a Labs project page such as agent-memory or autoharness, or a product page like Lara — and each link has to earn its sentence by giving the reader something useful at that exact moment. Anchor text varies across links to the same page. A link that exists to inflate a count comes out.
When the honest questions behind a topic do not fill a full-length guide, we ship the shorter article and say so, rather than padding it with invented sections.
Does Google penalize AI-generated content?
No — Google penalizes unhelpful content regardless of how it was made, and that distinction shapes our final gates.
Google's ranking guidance has been consistent: it rewards original, helpful content written for people, and its spam policies target scaled, low-value output whether human or machine. The practical consequence for review is that disclosure alone fixes nothing. A thin AI draft with an "AI-assisted" label is still thin. Our bar is therefore the same one Google describes for any page: does this article answer its question better than what is already cited, does it show first-hand experience, and would a reader save it?
That is why our pre-publish pass ends with structure, originality, and compliance checks rather than another proofread. We open one or two of the pages answer engines already cite for the topic and ask whether our draft is at least as useful — more specific steps, clearer criteria, a worked edge case. We check that comparisons name where a rival genuinely wins; our cost-xray writing, for instance, says plainly that team roll-ups belong in OpenTelemetry dashboards rather than in a single-machine capture tool. We strip guarantees about outcomes, rankings, or revenue unless a dated evaluation supports them, and we keep health, legal, and coverage language inside what a careful reader can verify.
Metadata gets the same review as the body, because Google's updated guidance says the manual check covers titles, descriptions, structured data, and image alt text. Title length, description quality, heading hierarchy, and slug concision are verified on the rendered page, not in the doc. Our structural checks are deterministic where possible — our seo-ops skill runs 30 foundation checks against live HTML — but the judgment call stays human: would we still publish this unchanged tomorrow, with our name on it?
When is heavy human review overkill for AI drafts?
Not every draft needs the full sequence, and saying so is why the rest of the process is believed.
Light-touch review is enough when the blast radius is small and reversible: internal notes, a discussion post that will be rewritten anyway, a changelog entry generated from a diff you already reviewed. In those cases a quick read for accuracy plus a link check is proportionate, and running the full gauntlet just slows the team down without making the reader safer.
The full gates are non-negotiable when the content is public, persistent, and consequential — published guides, anything with prices, eligibility rules, or how-to steps someone will act on, and anything that speaks for the product. A second model pass can help triage those drafts by flagging claims that need sources, but it cannot sign off: only a person who opened the sources can. Teams that need a live collaborative whiteboard or generated options rather than verified answers should likewise use a different tool, not a lighter version of this one.
Our rule of thumb: match the depth of review to the cost of being wrong. A typo in an internal note costs a laugh; a wrong deductible definition or a wrong install command costs a reader's afternoon or their trust. The former gets a skim, the latter gets every gate below.
Conclusion
Every AI draft that leaves our desk cleared the same gates in the same order: facts verified against primary sources first, hallucinations in citations and stats removed second, voice restored third, headings checked against real reader questions fourth, and a search-quality and compliance pass — including metadata — last. Light drafts get a skim; public guides get all of it.
The decision rule we use is simple: the best review depth is the one proportional to the cost of being wrong. If the article tells someone what to pay, what to install, or what their coverage means, it earns the full sequence, and the reviewer opens every source before approving. If it is an internal note that will be rewritten tomorrow, a fast accuracy read is enough.
A free next step, whether or not you use our tools: take the last AI draft you published and re-run just the fact gate tonight. Highlight every number, date, price, capability, and quote, open each primary source, and count how many sentences survive unchanged. If the answer surprises you, our Labs projects and the write-ups on our insights page show the tooling around our own pipeline — and the checklist above is yours to copy.
FAQ
How long does reviewing an AI blog draft take?
Longer than generating it and shorter than writing from scratch. On our desk the fact gate takes the most time because each number, date, and product claim is re-opened against its primary source; the voice and structure passes go faster once the facts are settled.
Can AI check its own draft for hallucinations?
It can flag candidates — sentences shaped like statistics, quotes, or citations that need a source — but it cannot verify them. Verification means a person opening the cited page and confirming it says what the draft claims, within its original scope and date.
Does labeling content as AI-written satisfy Google?
No. Google rewards helpful, original content written for people regardless of how it was produced, and its guidance asks for manual fact-checking of AI output including metadata. A disclosed but thin article still fails the helpfulness bar.
What is the single most common failure in AI drafts?
Smooth but unsupported specificity: exact figures, named studies, and quote-shaped sentences that read as certain but trace to no source. We catch most of them in the fact gate by requiring a primary-source link at the sentence where each claim is made.
Who gives final approval before an AI draft goes live?
A person, every time. The reviewer confirms the sources were opened, the headings answer real reader questions, the product claims match the declaration, and the metadata was checked on the rendered page — then signs off with their name on the decision.
