A hallucination is output containing facts that are inconsistent with reality or unverifiable, and product facts are exposed to it whenever they change faster than the systems describing them. Pricing, integrations and compliance claims carry the most risk because they change often and are rarely stated in machine-readable form on the pages engines retrieve.
Published knowledge cutoffs make the staleness concrete: a model whose knowledge stops in January cannot know a price you changed in March.
What counts as a hallucination?
The research literature splits it in two, and the distinction is useful because only one half is your problem. The widely cited survey on hallucination in large language models by Huang and colleagues defines factuality hallucination as output containing “facts that are either inconsistent with real-world facts or unverifiable,” with two subtypes: factual contradiction, where the fact could be grounded but is contradicted, and factual fabrication, where the fact is “unverifiable against established real-world knowledge.”
The other half is faithfulness hallucination, where the output diverges “from user input or the lack of self-consistency within the generated content.” That matters to people building applications on these models. It is not what happens when an engine misstates your pricing to a buyer.
Your exposure is factuality, and specifically factual contradiction: the fact exists, it is checkable, and the engine has an outdated or wrong version of it.
Why do product facts go wrong specifically?
Because they move. A company’s founding year is fixed forever and its pricing changes annually or faster, and a model’s memory of both was fixed at the same moment.
Those moments are published. Anthropic’s models overview lists a knowledge cutoff for every current model, distinguishing a “reliable knowledge cutoff” that “indicates the date through which a model’s knowledge is most extensive and reliable” from a broader “training data cutoff.” The dates differ between models in the same family, running from January 2026 to May 2026 across the current generation at the time of writing.
So the question is not whether a model’s picture of you is stale. It is how stale, and whether anything current is reachable to override it.
The model’s stored version is last year’s. Unavoidable and not your fault.
No fetchable page states the new value plainly, so retrieval cannot correct the memory. This one is yours.
Which of your facts are most exposed?
Rank them on two axes: how often the fact changes, and how machine-readable it is where it lives. High change and low readability is the danger zone.
| Fact | Changes | Usually stated as | Exposure |
|---|---|---|---|
| Pricing and plan limits | Often | A styled pricing table or an interactive widget | High |
| Integrations supported | Often | A logo grid with no text | High |
| Compliance and certifications | Periodically | A trust page, sometimes behind a form | High |
| Product capabilities | Often | Marketing prose, which is retrievable | Medium |
| Headquarters, founding year | Never | Structured data and third-party profiles | Low |
The pattern in the third column is the actionable part. Logo grids, pricing widgets and gated trust pages are all ways of stating a fact that a retrieval system cannot easily lift. A logo is not a sentence, and an engine reading your integrations page may find no text asserting that you integrate with anything.
If the only place you state a fact is inside an image, a widget, or behind a form, you have not stated it to a machine.
What does a wrong fact actually cost?
More than a missed mention, because it converts presence into damage. Being absent from an answer costs you a chance. Being present with the wrong price costs you a buyer who disqualified you on a number you do not charge.
Compliance is the sharpest version. A buyer told you lack a certification you hold will not write to ask, and there is no impression in your analytics to investigate. The failure is silent by construction.
It also compounds differently from a visibility problem. A visibility gap gets better as more sources mention you, but a wrong fact gets worse, because each repetition makes the incorrect version better attested than the correction.
How do you reduce the exposure?
Make the volatile facts retrievable as plain sentences, on pages that are reachable. Three moves cover most of it.
State each volatile fact in text on a page an engine can fetch. Google’s documentation on AI features sets the requirement as a page that “must be indexed and eligible to be shown in Google Search with a snippet,” and adds that there is no special markup needed. Plain, indexable prose is the mechanism.
Write the fact in a self-contained sentence. “Rivarise Business is $349 a month and includes all nine engines” survives being lifted out of context. A table cell reading “$349” does not, because the cell loses its row and column headers when chunked.
Put the same fact in more than one place. Anthropic’s citations documentation describes returning “the exact passages that support each claim,” so the fact needs to exist as a passage somewhere retrievable. One page is a single point of failure; a pricing page, a docs page and a FAQ answer is redundancy.
Should you try to correct an engine directly?
Correcting it inside a conversation does nothing durable. The engine will accept the correction, apologise, and use the right figure for the rest of that session, and none of it persists past the conversation. Nothing about that exchange reaches the next user asking the same question.
The durable version is to change what the engine reads. That means publishing the correct fact plainly, making sure the page is reachable, and where a third-party source carries the wrong version, asking that source to update it. A wrong price on a widely-cited comparison page will outrank your own correction for as long as it stands.
This is slower and it is the only thing that works. The single exception is where a vendor offers a genuine feedback channel, which is worth using but should not be mistaken for a fix with a timeline attached.
How do you monitor for it?
Track attribute questions separately from visibility questions, because they behave differently and fail differently. Ask each engine directly what you charge, what you integrate with, and what you are certified for.
Score those as correct, stale, or fabricated rather than as a presence rate. A stale answer means retrieval is not reaching your correction. A fabricated answer means nothing authoritative exists for the engine to find, which is a content gap rather than an access problem.
Expect the fix to land at two speeds. A retrievable correction can change answers within days, while the model’s underlying memory only updates across generations, which is the split in why training data and live retrieval differ. Disagreement between engines on the same attribute usually means an unresolved identity rather than a content problem, covered in what is an entity in AI search.
Run the attribute check on a fixed schedule and keep the answers. The method for finding what an engine currently believes about your product is in AI giving wrong information about my product, and the sampling discipline that stops a single odd answer being read as a trend is in why ChatGPT gives different answers to the same question.