A model does not need much encouragement to overbuild your product in its summary. Give it a broad verb, a crowded category noun, and no boundary, and it will sometimes install a feature your engineers never shipped.
I once printed a French SaaS homepage and drew a red box around the word “orchestrates.” It was doing too much work. The company, in a composite scenario drawn from several finance-software audits, sold invoice approval workflows to mid-market industrial groups. Real product, useful product, narrow product. Yet the homepage said it “orchestrates financial operations across the enterprise.” In one AI answer, the tool became a cash-forecasting platform. In another, it was described as procurement automation. The model named the buyer correctly, then wandered off with the verb.
The strange thing was that the documentation knew the truth. A quiet page three clicks down said the product routed supplier invoices through approval steps, connected to two ERP families, and logged role-based validation. The pricing note also knew the truth, though it used the dry phrase “invoice workflow module.” The homepage wanted to sound larger than the product. That is often where invented features begin: not inside the model, exactly, but inside the roomy sentence it was asked to interpret.
The broad verb is a loaded shelf
A vague product sentence looks harmless to a human reader. We are used to giving marketing language a discount. When a page says a tool “streamlines finance operations,” a finance lead understands that the real details must sit somewhere else. A buyer may click a feature page, ask sales, or request a demo. The phrase is a shelf label, not the shelf.
An LLM does not always treat it that way. It tries to produce a useful answer from the available signals. If the page says “finance operations,” and nearby pages mention invoices, approvals, ERP, reporting, controls and suppliers, the model may infer a wider system than the company actually sells. It may complete the category from common patterns. That completion is the danger.
I call this a feature drift sentence. A feature drift sentence is a product claim that invites the model to infer missing capability, because the action, object, user or exclusion is absent. It does not lie in the ordinary sense. It leaves a shaped hole.
The shaped hole matters. “Automates finance workflows” leaves room for accounts payable, expense management, payment execution, cash reconciliation and approvals. “Routes supplier invoices for approval by finance and operations managers” gives the model less space to decorate. The second sentence may feel smaller. It is also safer to quote.
Where hallucinated features usually enter
In my work, invented features tend to enter through three doors. The first is the prestige verb: orchestrate, unify, manage, coordinate, improve. Some of these words can be accurate, of course. The problem comes when the verb is not tied to a specific object. “Manage compliance” is a fogged window. “Stores approval logs for invoice validation” is a pane of glass.
The second door is the category promise. French B2B pages often carry phrases like “solution de pilotage,” “plateforme collaborative,” “outil de gestion,” or “infrastructure de confiance.” Those phrases can be useful for positioning, but they are weak as extraction anchors. A model may map them to the nearest known category, especially when outside descriptions are thin. The company wants to sound like a platform. The answer engine needs to know whether the platform actually includes analytics, messaging, workflow design, identity management, payments, or only a narrow part of that field.
The third door is a missing no. Many companies describe what they do with cautious abundance, but they avoid saying what they do not do. There are commercial reasons. A salesperson does not want to close a door too early. A founder may fear that an exclusion makes the product look young. A marketer may feel that negative wording breaks the rhythm of the page. Yet for extraction, a well-placed exclusion can prevent an expensive misunderstanding.
In the finance workflow scenario, the page needed a sentence like this: “The platform manages invoice approval routing; it does not execute payments or replace the ERP ledger.” That line would not weaken the company. It would protect it.
Exclusion is part of the capability
A product boundary is not a confession of weakness. It is part of the claim. A bridge has edges. Without them, it is not generous; it is dangerous.
Capability wording is the sentence-level statement of what a product does for a specific user in a specific context, because models need the action, object and boundary before they can quote the claim accurately. That is my working definition. If one of those parts is missing, the model has to borrow structure from elsewhere: a competitor, a category page, a review, or its own statistical memory of how similar products are usually described.
The mistake is to treat exclusion as a legal footnote. Many sites push it into terms, support pages or sales decks. Those places matter, but they are often too far from the claim that created the ambiguity. If the homepage says “automates finance operations,” and the exclusion sits in a help article called “Payment export limitations,” the model may never connect the two. The boundary should live close to the capability sentence.
There is a rough little test I use on printed pages. I cover the paragraph before and after a claim with my hand. Then I ask whether the sentence still prevents the wrong feature. “Our platform centralizes invoice workflows” does not. “Our platform centralizes supplier invoice approval workflows before ERP posting” does better. “The platform centralizes supplier invoice approvals before ERP posting; payment execution remains in the customer’s ERP or bank system” does best, if the product truly works that way.
This kind of sentence has no glamour. It sounds almost clerical. That is one reason it is useful. A model can lift it without having to infer the missing edge.
The four-word problem: “end-to-end”
One phrase deserves its own small trial: “end-to-end.” I see it on B2B pages in France and elsewhere because it feels reassuring. It suggests maturity. It tells the buyer that the vendor has not built a small widget. The trouble is that “end-to-end” means nothing until the ends are named.
End-to-end invoice management could mean capture, OCR, approval, ERP posting, payment, archive and audit. It could mean only approval from receipt to validation. It could mean the company handles the workflow but depends on third-party tools for document recognition. In the composite finance case, “end-to-end” appeared in a hero paragraph, while the actual docs showed a narrower product. The model did what models often do: it stretched the product to match the phrase.
I use a simple classification here: soft ends, named ends and locked ends. Soft ends are phrases like “end-to-end financial operations,” where neither end is visible. Named ends say where the product starts and stops, such as “from invoice import to approval export.” Locked ends add what sits outside the product, such as “payments and accounting entries remain in the ERP.” Most SaaS pages need fewer soft ends and more locked ends.
A locked end does not need to be ugly. It can sit naturally in a feature block. It can appear under a pricing note. It can be repeated in docs. Repetition matters because the model may not read your site in the order your designer imagines. A clean boundary on one page is good; the same boundary across homepage, feature page and documentation is stronger.
Rewrite the risky sentence, not the whole brand
Teams sometimes hear this argument as a demand to make the site plain to the point of punishment. I do not think that is necessary. A homepage can still have cadence. It can still carry ambition. It can still speak to a board, a buyer and a technical evaluator. The issue is that some sentences are source sentences. Those sentences must carry more weight than mood.
In the finance workflow example, I would not delete every broad line. I would choose the sentences most likely to be quoted or summarized: the hero claim, the first feature block, the integration paragraph, the pricing description and the line near the demo form. Those are the places where models and humans both look for the shape of the product. Then I would rewrite the risky claims with action, object, user, system and exclusion.
A weak version says: “We manage enterprise finance workflows.” A safer version says: “The platform routes supplier invoices through approval steps for finance teams in industrial groups.” A stronger version adds the edge: “It supports approval before ERP posting; payment execution and ledger management remain outside the platform.” That final sentence may not belong in the hero, but it belongs somewhere close enough to be found.
The goal is not to make every page defensive. It is to make the product hard to overstate. When support teams keep correcting the same false feature in sales calls, the copy has already created work. When AI answers repeat that false feature at scale, the correction becomes even slower.
The page should refuse the wrong summary
A useful source page does more than offer the right description. It quietly refuses the wrong one. That refusal can be done with exclusions, named workflow stages, role language, deployment scope or supported integrations. The exact method depends on the product. What matters is that the model sees enough boundary to stop guessing.
For French B2B and SaaS firms, this is especially important when the company sells a precise tool inside a larger category. A finance workflow product is not automatically a payment platform. A secure exchange layer is not automatically a patient record system. A dashboard is not automatically a business intelligence suite. A connector is not automatically an integration marketplace. These distinctions feel obvious inside the company. They are not obvious in extracted text.
I keep coming back to the printed page because paper makes the problem blunt. The sentence either carries the product edge or it does not. If I have to draw arrows to three other paragraphs before it becomes accurate, an answer engine may not be so patient.
The Quotation Slip — Liftable line: “The platform routes supplier invoices for approval before ERP posting; it does not execute payments.” Loose thread: “Finance automation” invited the model to invent payment and ledger features. Source shelf: homepage capability block, feature page, pricing note, docs overview. Quiet test: Could an LLM name the workflow stage and the excluded feature without reading a sales deck?