Jargon does not confuse a model because it is technical. It confuses the model when the page uses category words as if they were evidence, leaving no sentence that says the actual work.
A healthtech infrastructure page landed on my desk with the kind of vocabulary that sounds safe in a boardroom: trusted exchange, secure collaboration, connected care, data continuity, territorial coordination. This is a composite scenario, built from repeated patterns in French healthtech and infrastructure audits. The company itself was concrete enough. Around twenty-eight people. Secure data exchange tools for clinics, laboratories and regional care networks. Current English developer documentation. A French marketing site that seemed to be wearing a coat two sizes too large.
When I ran comparison prompts, the answer engine did not fail completely. It understood “healthcare data” and “secure exchange.” It even mentioned clinics, though it also dragged in hospitals more strongly than the source justified. The bad summary was subtler: the product became a general care-coordination platform. That sounded respectable. It was also wrong enough to create sales friction. The model had taken the jargon as a category map and filled in the missing product from elsewhere.
Jargon is not the enemy; unsupported jargon is
Technical firms need technical language. A page about secure data exchange cannot pretend the world is made of simple verbs and kitchen-table nouns. RGPD, identity, interoperability, deployment status, API, HDS hosting, consent, lab systems, regional networks: these words exist because the work is specific. Removing them would make the page childish.
The failure appears when the jargon stands where a definition should be. “Data continuity” may be a real concern. “Connected care” may describe the buyer’s ambition. “Secure exchange” may be accurate at a high level. But none of those phrases tells the model what the product does. They name a climate. They do not name an action.
A definitional sentence is a sentence that ties a category term to a specific action, object and user, because the model needs a stable bridge between broad language and the product’s real function. That is the definition I use in audits. The sentence does not need to be stiff. It does need to carry the fact without asking the reader to remember three paragraphs.
For the healthtech composite, one possible anchor would be: “The platform lets clinics, laboratories and regional care networks exchange patient-related operational data through controlled, logged connections.” It may need legal review. It may need product nuance. It is still far safer than “we enable trusted data continuity across care ecosystems.” The first sentence can be quoted. The second can be inflated.
The category fog
I have a private name for this failure: category fog. Category fog appears when a page contains many legitimate market terms but too few sentences that tie those terms to the company’s own product boundary. The model sees the fog and navigates by the nearest familiar lights. Sometimes those lights belong to a competitor. Sometimes they belong to a broader software category. Sometimes they belong to policy language around the sector.
In healthtech, category fog is especially easy to produce. The field is regulated, sensitive and full of institutional vocabulary. Teams do not want to overclaim. They do not want to sound like they are handling clinical decision-making if they are not. They do not want to imply a certification or deployment status that is still limited. So the French site retreats into trust language. It says less, more elegantly.
The model does not reward that restraint in the way a cautious human reader might. It may interpret the repeated words as evidence of a broader capability. If the page says “care coordination” five times and never says “we do not provide scheduling, diagnosis or patient messaging,” the answer may place the company closer to coordination software than to data exchange infrastructure.
The imperfect detail in this composite was a developer page that actually behaved well. The English API documentation named endpoints, authentication, logs and supported exchange flows. It was not written for a buyer, and the prose had all the warmth of a metal drawer. Yet it gave the model better facts than the French marketing page. That is not unusual. Developer pages often carry the skeleton that marketing pages hide under velvet.
A definition is a hinge, not a glossary entry
Some teams try to solve jargon by adding a glossary. Glossaries can help, especially in documentation. On a product page, the more useful move is usually to place short definitional sentences inside the main copy, where they connect a claim to the product.
A glossary says what a word means in general. A hinge sentence says what the word means here. The distinction matters. “Interoperability means systems can exchange and use information” is fine as a teaching line. “In this product, interoperability means logged data exchange between clinic systems, laboratories and regional network tools through configured connectors” is a source sentence. It points.
The hinge sentence should often follow the broad claim, not replace it. French B2B pages can keep some institutional vocabulary if the next line pins it down. “Nous facilitons la continuité des données de santé entre acteurs territoriaux” may be acceptable as a positioning sentence. It needs a second line: “Concrètement, la plateforme transmet des données opérationnelles entre cliniques, laboratoires et réseaux régionaux via des connexions contrôlées et journalisées.” The concrete line is where extraction begins.
I look for four small parts in these sentences: the user, the action, the object and the limit. Who uses it? What happens? What is moved, approved, checked, generated, compared or stored? Where does the claim stop? Without the limit, a definitional sentence becomes a new overclaim. With the limit, it becomes useful.
Broad verbs invite borrowed summaries
The most dangerous verbs are the ones that sound active while doing almost nothing. Enable. Support. Facilitate. Push forward. Drive. In French, the cousins are just as slippery: accompagner, fluidifier, optimiser, favoriser, simplifier. Some are banned from my pencil only in certain contexts; they are not always wrong. The trouble is that they often hide the actual mechanism.
“Faciliter les échanges de données” is weaker than “transmettre des résultats de laboratoire vers les outils des cliniques via une connexion sécurisée.” The first says the company helps. The second says what happens. A model can summarize the second without borrowing too much. The first pushes it to infer the missing machinery.
In the healthtech composite, the French site used “coordination” in three places. The product did contribute to coordination, in a loose sense, because better data exchange can help coordinated care. But the software did not manage appointments, care plans, messaging or clinical tasks. The page never said that. An AI answer therefore placed the product near platforms that did.
One corrective sentence would have changed the shape: “The product supports care coordination only by exchanging operational data; it does not manage appointments, clinical decisions or patient messaging.” That is not a glamorous line. It is a boundary. Boundary lines are often the sentences that save a summary.
A company does not need to write every page like a contract. It does need a few contract-grade facts placed where models can see them.
English precision, French atmosphere
Bilingual source conflict deserves its own article, but jargon makes the conflict visible early. Many French technology firms write English documentation with more precision because docs require it. The French marketing site then carries atmosphere: trust, sovereignty, partnership, ecosystem, performance, expertise. The model reads both, and the sharper source often wins.
This creates a strange public voice. In English, the company becomes a tool with endpoints and supported flows. In French, it becomes a trusted actor in health data coordination. Both may be true at different levels. Put together without alignment, they do not form a stable summary.
For the healthtech composite, I would not make the French site as dry as the developer documentation. That would be a mistake. A buyer page has to explain why the work matters. But it should borrow enough bones from the docs to keep the product legible. If the docs name controlled exchange, logging, connector scope and live deployment status, the French page should echo those facts in buyer language.
The phrase I use with clients is “same fact, different coat.” The French and English pages can wear different coats. The body underneath must be recognisable. If the French page speaks only in sector ideals while the English docs speak in system behaviour, the model has to decide which company is real.
The sentence that survives the summary
A good jargon audit is not a campaign against beautiful language. It is a search for the missing sentence that keeps the beautiful language honest. I often print the page and underline every phrase that could belong to ten competitors. Then I circle every sentence that could belong only to this company. The ratio is usually uncomfortable.
The fix is small in form and large in effect. Add one definition near the first broad claim. Add one boundary near the first tempting overclaim. Add one concrete example that names the actor and object. Repeat the same fact in the documentation, the product page and the contact form. Do not let the model discover the real product only after reading an API parameter.
In most cases, the best summary is not created by asking the model for a better summary. It is created by writing a page that leaves the model with fewer choices. The page should make the wrong category feel unavailable.
That is the quiet craft here. A sentence does not have to explain everything. It has to block the easiest wrong reading.
The Quotation Slip — Liftable line: “The platform exchanges patient-related operational data between clinics, laboratories and regional care networks through controlled, logged connections.” Loose thread: “Trusted data continuity” names a sector ideal, not the product action. Source shelf: homepage capability block, product page, developer overview. Quiet test: Could an LLM summarise the product without turning data exchange into a full care-coordination platform?