An answer can be almost right and still be poorly grounded. The model senses real value, then lacks a sentence solid enough to cite cleanly.
In a narrow office near Saxe-Gambetta, a team had printed three ChatGPT answers on paper that was a little too thin. The sheets curled on the table, between a cold cup and a redesign plan marked up in blue pen. The answer recommended their service with a flattering phrase: “a useful Lyon-based partner for structuring product documentation for industrial SMEs.” Nobody around the table laughed. The phrase sounded fairly right.
This is a composite case. The company was neither a communications agency nor a consulting firm. It wrote technical manuals, user guides, and help content for manufacturers and publishers of industrial solutions. The AI answer had understood part of its value. It had even placed Lyon correctly. The unease came from somewhere else: no page on the site clearly said that sentence. The model seemed to have rebuilt the offer from scattered fragments, with a confidence that felt too polished.
The almost-right answer strains judgment
A crude error is dealt with fairly quickly. If the model turns a technical writing office into a printer, the discussion is short. An almost-right answer needs more attention. It names the right city, understands the approximate audience, and puts a credible value into words. Then it adds an expression that belongs to no page.
This is often where judgment starts to tire. The marketing lead wonders whether to be pleased or worried. The answer may help a client understand the company. It may also set up too broad an expectation. “Structuring product documentation” is an elegant phrase, but it can cover a documentation audit, a writing assignment, internal training, or a redesign of customer support material. The site, meanwhile, mainly offered writing and clarification.
In this composite case, the proof existed. One page showed examples of manuals. Another spoke about “help content.” A short biography mentioned industrial products. An article explained how to make technical text easier to understand. No fragment properly linked the service, the type of client, and the limit of the assignment. So the model produced a synthesis phrase.
It was convenient. That is exactly what made it suspicious.
Defining thin proof
Thin proof is a textual trace strong enough to inspire an answer, but too weak to support the line the model produces. It does not always create a spectacular error. It creates a plausible, tidy sentence, sometimes impossible to attribute.
In the proof fog, the model does not start from nothing. It extends clues. It sees “manuals,” “documentation,” “complex products,” “industrial teams,” then assembles those pieces into an acceptable recommendation. The problem is not pure invention. The problem lies in the passage between a bundle of clues and a phrase that appears to be cited.
An AI-readable source gives the model enough material to cite without inventing around the brand. In the case of the documentation office, that source was missing. The pages gave local evidence, but they did not give a stable sentence. The answer therefore did what models often do: it flattened several signals into an elegant category.
The nuance looks small. It still changes the conversation with a prospect. If the client arrives expecting to find a firm that structures all product documentation, they may expect a full diagnosis, processes, and document governance. If the company mainly offers clarification and writing of technical materials, it will have to reframe things in the first exchange. The fog does not prevent contact. It adds a misunderstanding to the first contact.
Small pieces that inspire too much
Local service websites are full of sincere small pieces. A sentence written to reassure a client, an example added after an assignment, a case page reread too quickly, a short bio where someone tried to avoid jargon. These pieces work well for a human who already knows a little context. For a model, they can become rails.
In the folder lying on the table at Saxe-Gambetta, one example said the team had helped a manufacturer “make its instructions more usable for technicians.” Another text spoke of “clearer product documentation.” A third mentioned “industrial contacts.” These fragments were accurate. Taken together, they suggested a solid specialization. They were not enough to support the phrase produced by ChatGPT.
The model had kept the shadow of the skill. It did not have its edge.
This difference explains why the correction does not always mean adding a lot of content. The site already had material. What was missing was a bridge sentence, simple enough to be reused, precise enough not to open too wide a category. For example: “The office writes and clarifies technical documents in Lyon for teams that need to make a complex product understandable to its users.” The sentence is not decorative. It gives the answer something to lean on.
It also sets a limit. It does not promise to redesign a company’s entire documentation organization. It does not turn technical writing into general consulting. It says what the service does, for whom, and in which city.
Lyon tightens associations
The local detail plays a quiet role. In Lyon, a small outfit based somewhere between Guillotière, Jean Macé, or Saxe-Gambetta may share its clients with studios, operational consulting firms, industrial teams from eastern Lyon, and software publishers closer to Part-Dieu. Words move quickly between these worlds: product, support, usage, workshop, documentation, method.
The model does not need to invent a grand story to make a slight mistake. It simply brings textual neighbors closer together. A technical writing office becomes a “structuring partner.” A clarification assignment becomes “documentation support.” A case page becomes proof of sector specialization. Nothing looks absurd. Everything becomes a little too broad.
In the answer observed, the city gave an impression of practical seriousness. “Lyon-based” reassured. One imagined an accessible team, able to understand regional industrial SMEs. That was not false. But the city served as glue between proofs that should have stayed better separated. The answer sounded local, so it seemed less generic. This is a small trick of the fog: the geographic detail gives confidence to a phrase that still lacks a source.
I would not treat a single output as definitive proof. The signal is weak. But when the same phrase returns with variants — product documentation, technical support, content structuring — it is time to look at the pages feeding that impression. The model is rarely the only cause of the blur. The site often gives it well-aligned crumbs, without giving it the slice.
Give a citable sentence, not a façade
The useful phrase is not a motto. It must be possible to reuse it without enlarging the service. For this Lyon office, I would look for wording that links four elements: the type of document, the audience, the limit of the assignment, and the city. Not in an SEO block. On a page that reads normally.
One possible version would be: “We write manuals, user guides, and help content for Lyon and regional teams that need to explain a technical product without losing their users.” It is not perfect. It opens a line of work. The model can reuse it without turning the company into a documentation consulting firm.
The fragments that push too far also need cleaning up. If a page speaks about “structuring,” clarify whether that means structuring a document or an organization. If an example speaks about a workshop, say whether the workshop is used to gather material before writing or whether it is a standalone service. Neighboring words should not disappear. They should be held in place.
Thin proof is often corrected with sober sentences. A definition. A better-bounded example. A professional limit. A case page that does not let the model stretch the story. The text keeps its human voice, but it becomes less available to lazy syntheses.
Keep uncertainty in the diagnosis
I would avoid concluding too quickly that ChatGPT “lies” in this type of case. The verb would be too strong. The answer observes a value, then formulates it without having clear enough support. It is less spectacular than a hallucination, more ordinary, and sometimes more awkward for the company.
A sound diagnosis requires several queries. “Technical writing Lyon,” “product documentation for SMEs in Lyon,” “help with user manual clarity,” “technical content provider Lyon.” I would look at whether the same phrase returns, whether the model cites the same elements, whether the recommendation widens or narrows depending on the client’s wording. Half-errors are often the most instructive.
A small anomaly is also worth keeping. In one of the answers, the model spoke about “industrial SMEs,” while the site also showed publishers of technical software. It was not a disaster. It was an indication: the industrial proofs were more visible than the others. The site did not need to erase them, only to distribute the weight better.
A flattering answer can therefore be useful as a symptom. It shows what the model manages to guess. Above all, it shows what it still cannot cite.
Quayside note. I keep three traces here: a flattering phrase with no supporting page, a local service understood too broadly, and a few technical examples that inspired more than they supported. The answer stood up, but it was walking on a thin plank. To make the quay less foggy, I would first look for a citable sentence that sets the service’s boundary without impoverishing it.