A false AI fact is rarely just a sentence to complain about. It is a little leak in the evidence system, and the repair starts by finding where the water entered.
A regional plumbing and heating network in western France once had a stubborn error that sounded harmless until the sales team explained the margin. AI answers kept describing the company as “emergency plumbing only.” The name was correct. Several branch locations were correct. The phone area looked plausible. But commercial heating maintenance, the work the company wanted more of, kept disappearing from the description.
This is a composite scenario, built from repeated patterns in local service audits. The rough detail matters: one answer also placed a branch in a nearby town where the company had an old review profile but no current office. The team had already edited the website. The false description still returned. That is the moment when a correction needs a ledger, not another round of hopeful rewriting.
A false fact has a history, even when we cannot see all of it
When an AI answer invents or repeats a wrong business fact, the reaction is usually personal. “Why does it say that about us?” Fair enough. A wrong description of a business feels like a stranger misreading your name badge and then giving directions to your clients.
The measurement question is colder: where could that false fact be coming from, and how often does it return? The answer may not be fully knowable. Some generated descriptions blend sources. Some systems do not show citations. Some errors come from old training data, retrieval snippets, copied directory text or several weak signals pointing in the same wrong direction. I do not promise a perfect origin story. I promise a traceable repair attempt.
A correction ledger is a repeated record of a false AI business fact, because the error must be traced through prompts, cited sources and retests before a fix can be trusted.
The phrase “repeated record” matters. One hallucinated answer may be noise. A false fact appearing across engines, languages or prompt types becomes a managed problem. If it returns after the website has been edited, the site was either not the source, not the strongest source, or not yet clear enough to overcome the older evidence.
That is annoying. It is also useful. Annoyance gives the work a starting point.
Do not correct the sentence first
The tempting move is to rewrite the page where the correct fact already exists. Add a paragraph. Change a heading. Insert a line in the homepage. There are times when this helps. But if the wrong fact is coming from a directory, old profile, partner page, review text or category association, rewriting the company page may only polish the truth in a room the engine is not entering.
In the heating network scenario, the company had already added maintenance language to its main service page. The false answer kept returning for several city prompts. The ledger showed why the team’s repair had missed the problem. The answer engine often cited, or seemed to lean on, branch-level profiles and directory pages that emphasized emergency plumbing. Some profiles had been created years earlier for quick-response work. They were not technically false, but they were commercially incomplete. The AI answer compressed the incomplete description into an identity.
That is a common mechanism. An old partial fact becomes a current total fact. The company once did emergency work. The page says emergency work. The model repeats emergency work. The buyer asks for maintenance, and the answer still carries the emergency label like a sticker left on a glass after washing.
Before correcting the sentence, I want the false fact written down exactly. Not “AI gets us wrong.” That is too soft. Write: “Describes company as emergency-only.” Write: “Places branch in Saint-Brieuc.” Write: “Calls us a reseller.” Write: “Says we serve only individuals.” The ledger needs the exact wrong claim, because vague frustration cannot be retested.
The four origins of a stubborn error
I use a simple classification for hallucinated business facts. It is not a scientific taxonomy; it is a working tool that keeps the repair from becoming theatrical. The four origins are stale, partial, borrowed and inferred.
A stale fact was once true or was true enough in an old context. An old address, former service line, previous partner status or outdated business description sits somewhere in the evidence field. The answer repeats it because the page remains retrievable or has been copied into other sources.
A partial fact is true but too narrow. The heating company does emergency plumbing, but not only emergency plumbing. A software firm resells licenses, but its main value is implementation. A regional office serves one city, but the service area is wider. AI answers often turn partial facts into complete identities because concise answers reward compression.
A borrowed fact comes from another entity. This happens with similar company names, franchise networks, branches, old acquisitions, or directories that mix nearby firms. The error may look invented, but it has a neighbor. In local markets, borrowed facts can be especially stubborn because location, category and name fragments overlap.
An inferred fact is the most slippery. No page says the wrong thing directly, but the engine infers it from category patterns. A company with many emergency-related pages may be described as emergency-only. A B2B service provider with vendor badges may be described as a reseller. A business with English partner listings and thin French case evidence may be described using the partner vocabulary.
I call this group the SPBI error map: stale, partial, borrowed and inferred. It gives each false fact a likely repair path instead of treating every hallucination as the same kind of machine mischief.
A stale error needs cleanup and stronger current evidence. A partial error needs fuller descriptions where the partial fact appears. A borrowed error needs entity disambiguation. An inferred error needs a better balance of signals so the system has less reason to complete the story wrongly.
A correction loop has to outlive the edit
Many companies stop too early. They find the wrong fact, edit a page, and assume the correction has happened. That is understandable. In ordinary publishing, once the page is edited, the page is edited. In AI visibility, the answer may not change until the better evidence is retrieved, weighted and repeated often enough to alter the pattern. Sometimes it changes quickly. Sometimes it does not. Sometimes one engine updates while another keeps the old shape.
My correction loop has four plain steps. I write them in prose here because lists make this work look cleaner than it is.
First, isolate the exact false fact and the prompts that produce it. The wording matters. “Emergency-only” may appear in broad “best plumber” prompts but not in “heating maintenance contract” prompts. Or it may appear in French but not in English. Or the English version may carry a different error because it cites partner pages.
Second, trace the sources. I open the cited pages when they are shown. When citations are absent, I search the wording around the false fact and inspect likely sources: directories, profiles, old PDFs, review pages, partner pages, local listings. I mark source confidence as shown, likely or unknown. That honesty prevents the ledger from becoming a detective novel with too neat an ending.
Third, strengthen the better source. This may mean correcting external profiles, clarifying branch pages, adding plain service descriptions, improving case evidence, aligning French and English wording, or making location facts less ambiguous. The better source must state the correct fact in a form that can be retrieved and summarized. A beautiful paragraph that hides the fact in soft language is not a correction.
Fourth, retest the same prompts after the change has had time to enter the answer path. I do not change the prompt set in the same move, because then I cannot tell whether the answer improved or the test moved. New prompts can be added, but the old ones remain as a control group.
The loop is dull by design. False facts love dramatic reactions. They are better handled with dated rows.
The correction may need more than your own site
There is a limit to the comfort of first-party control. The company owns its website. It may own some profiles. It does not own all the pages that describe it. A correction ledger makes that visible without turning it into despair.
For the heating network, several weak sources sat outside the main site. Branch listings emphasized emergency calls. Some descriptions were copied from older profiles. One location page on an external platform had a service-area hint that made a nearby town look like a branch. None of these sources alone explained every wrong answer. Together, they gave the engine a crooked outline.
The repair therefore had two tracks. The company strengthened its own branch and maintenance pages with clear service descriptions, city coverage and commercial maintenance language. It also corrected the external profiles it could access and marked the ones it could not. For sources outside its control, the team created stronger competing evidence: clearer public profiles, better case summaries, and consistent wording across locations.
There is no magic in this. A correction is not a request shouted at the model. It is a change in the evidence field. The engine needs enough better material to stop choosing the old shortcut.
I also watch for overcorrection. A team angry about being labeled emergency-only may remove emergency language everywhere. That can damage legitimate visibility for urgent repair prompts. The goal is not to erase the partial truth. The goal is to place it in proportion. “Emergency plumbing and planned heating maintenance” is a different signal from “24/7 emergency plumber,” and the distinction matters.
Retesting proves the repair or exposes the next source
The retest is where pride has to sit quietly. Sometimes the correction works in one engine and fails in another. Sometimes the false fact disappears from broad prompts but remains in location prompts. Sometimes the cited source changes but the description error survives. That last case is especially irritating. It means the wrong fact may be inferred from several sources, not copied from one.
In the heating network scenario, the first retest improved the maintenance prompts in French for two cities. The company was named with a better description and, in some runs, cited its own service pages. But one nearby-town prompt still described the firm as emergency-only and placed it awkwardly outside its real branch structure. The ledger pointed to a remaining external listing. Not a clean victory. A useful next repair.
This is why I prefer correction ledgers to “fix lists.” A fix list assumes the work ends when the task is checked. A ledger assumes the answer has to be observed again. AI visibility does not become manageable because we make one perfect edit. It becomes manageable because repeated answers show whether the edit entered the pattern.
There is a psychological benefit too. The team stops arguing from screenshots. One person is no longer waving the bad answer; another is no longer waving the edited page. Both are looking at the same rows: false fact, prompt, source, correction, retest result. The conversation becomes less theatrical.
A hallucinated business fact is not always removable on command. But it is usually classifiable, traceable enough to work on, and testable after repair. That is already much better than shouting at the answer box.
The Measurement Note — Signal: the same false business fact returns after the website has been edited. Distortion: treating the hallucination as one bad sentence instead of a source-pattern problem. Ledger: record the exact false claim, prompt, engine, language, cited or likely source, correction made and retest result. Next Test: classify the error as stale, partial, borrowed or inferred, then repair the strongest source first.