“Prevent hallucinations” is a useful goal only if it becomes a set of observable controls. A customer-facing chatbot can still make an unsupported claim because the source was absent, stale, contradictory, retrieved poorly, or stretched beyond its conditions. The practical response is layered prevention and fast diagnosis—not a promise that errors are impossible.
Diagnose the unsupported claim first
When a visitor reports a questionable answer, preserve the conversation, the wording of the question, the answer and its citation. Then classify the failure. Was there no source? Did the source not support the claim? Did two approved pages conflict? Was a relevant source available but not found? Or was the matter account-specific and therefore never suitable for a general answer?
This classification stops teams applying the same fix everywhere. Adding an FAQ cannot solve an individual order dispute. Rewriting a policy cannot fix a broken citation link. A question that retrieved no relevant knowledge may be a real gap; one that retrieved the right candidate but produced no answer may need retrieval or searchable wording work instead.
Use prevention in layers
| Layer | Practical control |
|---|---|
| Source boundary | Use approved pages and documents; exclude drafts, private notes and obsolete policies. |
| Content review | Resolve conflicts and assign owners to price, promise and policy changes. |
| Answer boundary | Require a source-backed answer or an honest limit with a human route. |
| Evidence | Show the source and retain a conversation record for later inspection. |
| Testing | Test both supported questions and questions the assistant must stop at. |
| Feedback loop | Review negative feedback, handovers and recurring unanswered questions. |
RobiFox describes its product boundary as approved knowledge, clickable sources and an honest refusal where coverage is absent. Its review workflow puts contradictory and duplicate material side by side for a human decision. These controls cannot make the original website true, but they make sources, limits and corrections visible. See How it works.
Make refusal a successful result
Teams sometimes accidentally reward a chatbot for answering every question. That encourages exactly the behaviour they are trying to avoid. Add test questions that have no approved answer: account status, a discount someone has not authorised, a discontinued product, or a policy exception. The desired result is a clear statement of the limit and a realistic way to contact a person.
RobiFox’s answer tests let an owner label questions the assistant “must know” and questions it “must stop” at; expected source pages can also be recorded. This is a useful pattern for a local acceptance set. Use the words visitors actually use, not only formal FAQ headings. The public measurement methodology similarly separates answerable and deliberately unanswerable questions, but its results are an internal benchmark rather than a promise about another site.
For the response itself, use the unsupported-question response guide. It separates clarification, a supported partial answer and an honest limit with a practical next step. This article focuses on preventing and repairing the cause of an unsupported claim.
Keep sources fit for use
Prevention begins before the model sees the content. Give every high-impact source an owner and a review trigger: price changes, a promotion end date, new shipping regions, amended terms or a product retirement. Treat a document that is merely “available somewhere” as unapproved until its scope and version are clear. A bot citing a stale policy is still showing evidence for a bad outcome.
When sources disagree, choose one or write a resolved statement rather than expecting the assistant to infer which is newer. RobiFox says operator edits are not overwritten by a later re-crawl, which supports this kind of deliberate correction. Its weekly re-read of website pages is useful for detecting changed material, but it does not replace business review.
Test after meaningful changes
Maintain a compact regression set around the questions that can cost money or trust. For a fictional outdoor retailer, that could include “Does the winter-sale price apply to gift cards?”, “Can I return a used climbing harness?”, “Do you ship batteries to Norway?” and “Can you tell me where my order is?” The last question should stop if the assistant has no order system access.
Run the set after a policy change, source update or configuration change. Check answer meaning, citation validity, relevant conditions and refusals. RobiFox’s methodology describes end-to-end measurement and notes that repeat runs can reveal variability. Compare the same questions, knowledge version and model; a single run is not a guarantee for future answers. Your own pass criteria should include source fit, not just a percentage.
Turn incidents into safer knowledge
A logged issue should result in one of four outcomes: correct an approved fact, resolve a source conflict, improve retrieval of existing knowledge, or document that the topic requires a person. Review the repaired question and close the incident only when the test proves the new intended behaviour. The conversation record and cited source make that work concrete; the missing-knowledge list helps prioritise it by frequency.
Source citations and tests do not guarantee perfection. They do give a business an accountable way to detect unsupported claims, reduce their recurrence and explain why a particular answer was or was not appropriate. Read How we measure and RobiFox features for the documented controls.
For the next step, build a repeatable accuracy test set.
Cover image: AI-generated editorial illustration, not a product screenshot.
What our own help test caught
In our 1 October 2026 Hungarian help test, the question “How many credits does a text-only conversation cost?” exposed a conflict in the retrieved knowledge: one passage described charging per answer, while another described charging per conversation. The assistant flagged the inconsistency and declined to give an unqualified billing answer. This is an observed result from the v2 test, not an invented customer story.
The test also asked for the visitor’s current personal credit balance. The assistant said it could not see that account-specific balance and pointed the visitor to the account screen. The full set recorded 11/12 expected refusal flags, so it did not meet our 100% target. The original responses let you check both the useful behaviour and its limits.
Read the dated methodology and original responses or download the 52-question result (JSON). This measures our own Hungarian documentation, not English answer quality or customer results.
