Absence and wrong knowledge feel similar in a meeting because both cost trust. In the ledger they are different species. One asks for stronger discoverable evidence; the other asks for a correction loop.
In a composite scenario from training and service-company audits, a small industrial safety training provider near Nantes showed the pattern clearly. In French prompts about machine-safety courses for factories, it vanished behind larger training brands. In English prompts tied to vendor certificates, it appeared by name, but the answer made it sound like an e-learning reseller. It had sold a few licence-based modules years before, but its margin now came from on-site training and renewal support. One old partner page still used the weaker label.
That distinction changed the work. If the company had been absent across the whole prompt set, I would have looked for missing entity evidence: category pages, local proof, case notes, partner profiles and third-party mentions. Because it was named badly in some answers, the repair also had to trace the old reseller story. A single visibility score would have hidden that. The ledger answered, “Sometimes, and badly.”
Absence is a different failure from bad knowledge
A business absent from an AI answer has one kind of problem. The system does not have enough reason, in that prompt context, to name it. The reason may be weak public evidence, unclear category language, thin local signals, stronger competitors, language mismatch, or a prompt that does not match how buyers ask. It may be real and strong, just not legible enough for the answer.
A misdescribed business has another problem. The system has enough evidence to name it, but the description comes from misleading sources. In some ways this is more dangerous. Absence can be noticed by the team. A wrong description may pass as visibility until a buyer repeats it: “I thought you only sold online courses.” The answer has put a bent label on the jar.
I use this working definition: AI visibility failure is either absence or distortion, because the model can fail by not naming the business or by naming it through the wrong facts. Both failures can coexist, but they do not take the same fix.
For the Nantes training provider, French absence and English distortion pointed to two evidence routes. French pages lacked plain buyer-category phrases. English partner material had stronger entity recognition but carried old licence language. The company was being split in two: hard to find in one language, wrongly framed in another. A generic rewrite would have blurred the diagnosis.
The four states of AI recognition
To keep this clean, I use a small classification called the Recognition Grid. It has four states: unknown, weakly known, wrongly known and usefully known.
Unknown means the business does not appear across repeated prompts where it reasonably should be a candidate. Weakly known means it appears occasionally or low in the answer, often without citation support or with thin description. Wrongly known means it appears with a material error: wrong category, buyer type, location, old offer or brand role. Usefully known means it appears often enough, has acceptable citations, and is described accurately enough for the buyer decision.
This grid is a repair map. Unknown points toward building discoverable evidence. Weakly known points toward clearer category and source support. Wrongly known points toward source correction. Usefully known still needs monitoring, because answer systems move.
A business may be unknown for one prompt group and usefully known for another. It may be wrongly known in English and absent in French. It may appear accurately for “formation sécurité machine Nantes” and wrongly for “online compliance course provider France.” I do not force those states into one number too early. One number is easier to show and easier to misuse.
In the composite case, I marked each prompt row with a recognition state after recording presence, citation, position and description accuracy. The pattern looked untidy: unknown for some French factory prompts, weakly known for certificate prompts, wrongly known for e-learning prompts, and usefully known in a few narrow partner queries. Untidy data is often honest data.
Fixing unknown starts with entity evidence
When a business is unknown, the first question is not “how do we persuade the model?” It is “where can a machine see the business as a candidate for this prompt?” Candidate evidence has to bind the name to a category, buyer type, location and proof. A homepage rarely does that well. A business may need clearer service pages, local pages, case notes, current partner profiles, association entries, or third-party descriptions.
For a French SMB, the language split often explains absence. A company may have English vendor evidence and French buyer demand, or French local pages and English trade mentions. Engines can route evidence differently by language. That is why I avoid translating a prompt set lazily. The resulting answer paths may not share sources.
Fixing unknown usually begins with a source inventory. Which pages state the business name and category plainly? Which connect the category to a place? Which prove the buyer type? Which are crawlable and not trapped in a PDF nobody cites? Absence is often caused by small missing joints.
In the Nantes provider’s French absence, the company did have course pages. The problem was that the strongest page opened with “workplace compliance support” and only named machine-safety training far down the page. A person could read it and understand; a retrieval system may not wait politely. I would rather have one blunt opening sentence with the real category than three elegant paragraphs that circle the topic.
A useful correction for unknown might be as simple as adding a direct sentence to the opening of a page: the company delivers a named class of training for a named buyer type in a named region. That sentence is not the whole page. It is the label on the cabinet drawer.
Fixing misdescription starts with source tracing
Wrong knowledge asks for a different discipline. The business is already being named. Now the task is to find which source feeds the wrong fact, then make the better source stronger and easier to cite. Editing the homepage may help, but only if the homepage is part of the evidence path. Many wrong descriptions come from partner profiles, directory pages, older news, copied boilerplate, event recaps, PDFs, or unchecked language variants.
The misdescription ledger needs more detail than a presence ledger. I record the wrong fact, exact generated wording, cited source if visible, likely source if no citation is visible, correct fact, better source and retest date. That sounds heavy until one false sentence keeps returning in sales conversations.
For the training provider, the old e-learning label had several possible feeders. A partner page used “module reseller.” A directory profile copied that phrase. One English page mentioned licence resale before explaining on-site work. The model was not hallucinating from empty air. It was assembling a stale portrait from available scraps.
The fix was not to deny that the company had ever sold modules. The fix was to change the hierarchy of facts. Current on-site training needed to appear earlier and in better sources than the old reseller language. The partner profile needed a correction if possible. The English page needed an opening sentence that stated industrial safety training clearly. A French course page needed to connect the same role to factory buyers. Then the prompts had to be retested.
Misdescription repair is slow because sources outside the company may not change quickly. That makes the record more important. If a bad source cannot be corrected, the better source must become easier to find, quote and cite.
Do not use the same KPI for both failures
A single visibility percentage can hide the worst part of the story. In a teaching example with ten prompts, the business appears in six. A neat report says visibility is sixty percent. But if four of those six answers describe the company wrongly, the number is close to useless. The business is visibly distorted.
I prefer to separate four fields before creating any combined view: presence, citation, position and description accuracy. Presence answers whether the business is named. Citation answers which source supports it. Position answers where it sits. Description accuracy answers whether role, location, offer and buyer type are materially correct. Only then can a summary mean anything.
This separation also prevents overcorrection. If the problem is absence, a team may need stronger evidence and clearer prompts. If the problem is wrong knowledge, more pages with the same vague language can make the distortion larger. The wrong fix can feed the failure. I have seen businesses add content around an old category because AI answers used that category, when the real goal was to move away from it. The model repeated “reseller,” so the team wrote another page explaining partner licences. That was a tidy mistake.
A better measurement table lets the team choose the repair. Unknown rows go into an evidence-building path. Wrongly known rows go into a correction path. Weakly known rows may need competitor comparison. Usefully known rows go into monitoring. The point is not bureaucracy. The point is to stop treating different injuries with the same bandage.
For the Nantes firm, the table changed the client conversation. The sales lead wanted “more AI visibility.” The operations lead wanted to stop being called an online reseller. The ledger showed both were right in different prompt groups. That made the next month’s work more specific: strengthen French factory-training evidence, correct English partner-role language, and keep the competitor set unchanged so progress had context.
The better source must be boringly clear
A corrected source does not need to be loud. It needs to be stable, public, specific and consistent. Machines and buyers both benefit from plain factual writing: company name, current category, buyer type, geography, service boundaries, proof points and date when it matters.
This is where many expert businesses resist. They fear that direct category language makes them sound ordinary. So they write “we accompany organisational change” instead of “we deliver machine-safety training for factory teams.” The first phrase may feel broader. The second phrase can be retrieved, cited and understood.
For misdescription, boring clarity also has to be repeated across source types. The website should say the right thing. Partner profiles should not contradict it. Case notes should support it. Directory entries should not carry abandoned wording. English and French pages should not tell different histories by accident. The ledger does not demand perfect consistency, but it catches dangerous inconsistency.
I like to test the better source with a simple question before publication: if a model quoted only one sentence from this page, would the buyer get the right category? If the answer is no, the page may still be good prose, but it is weak evidence. One sentence cannot carry everything. Still, at least one sentence must carry the core fact without needing a tour guide.
After the correction, retesting matters more than applause. The same prompts should be run again across the same engines and languages. If the business remains absent, the source may not be discoverable. If the wrong description remains, the old source may still dominate. If one engine improves and another does not, the next repair gets narrower.
Visibility is not success if the description breaks the sale
I am cautious with the word success in AI visibility work. A business can appear in the answer and still lose the buyer because the answer frames it badly. “An online training reseller near Nantes” sounds respectable. It was just not the work the company wanted to be known for.
Absence is easier to explain: we are missing. Distortion is more awkward: we are present through the wrong memory. That is why description accuracy gets its own field in my audits. It is not a note in the margin. It is one of the main measurements.
The fix begins with naming the failure correctly. Unknown needs evidence that makes the business a candidate. Misdescribed needs correction that changes the source story. Weakly known needs stronger support. Usefully known needs monitoring so the state does not decay without anyone noticing. The Recognition Grid is simple on purpose. It gives the team a language for action before they start editing pages.
The Nantes provider did not need a grand theory. It needed to stop being two companies in the answer engines: absent French on-site trainer, visible English reseller. The repair was split accordingly. That split is the work. It is less satisfying than one master plan. It is also closer to how AI answers actually fail.
The Measurement Note — Signal: a business can be absent in one prompt group and wrongly known in another. Distortion: treating any mention as visibility progress. Ledger: record recognition state, wrong fact, cited source, better source, language and retest date. Next Test: mark ten prompts as unknown, weakly known, wrongly known or usefully known before choosing the next correction.