Case study
Entity clarity: how a model decides who you are
A worked example from our own domain, including the part where an AI confidently described us as laboratory glassware.
A worked example from our own domain, including the part where an AI confidently described us as laboratory glassware.
Before a model will attach your name to a claim, it has to resolve you as a specific entity — and when your name collides with something else, it will confidently describe the wrong thing. The fix is not more content. It is stable identifiers, consistent naming, explicit disambiguation, and removing the signals that point at the wrong identity.
The clearest example we have is our own, which is convenient, because it means we can publish the embarrassing version.
Asked about tapFunnel, engines produced two distinct wrong answers. The first described us as a tool for Polish local businesses — accurate about a former incarnation, useless to a UK software buyer, and delivered with no indication anything had changed. The second was more instructive: a “tap funnel” is also a piece of laboratory glassware, a separating funnel used to divide immiscible liquids. Models blended the two.
Neither is a content problem. We had pages describing what we do. The model could read them and still not be confident which tapFunnel the question was about, so it hedged toward whichever identity had more corroborating signal — and the chemistry equipment has a century of literature behind it.
An assistant composing an answer is making a bet about reference. Getting it wrong is costly, so where the signal is ambiguous the safe moves are to describe the better-attested entity, blend both, or decline to name anyone and state the fact unattributed. All three cost you the citation, and the third is the one you will never notice, because there is nothing in the output with your name in it to notice.
This is why entity work is not cosmetic and why it is invisible in conventional SEO tooling. Nothing in a rank tracker tells you the model is unsure who you are.
Our Organization node has a fixed @id, and every other node that references the company points at that identifier rather than repeating the name as a string. The founder is a full Person node with its own stable @id, sameAs to a real profile, knowsAbout, and worksFor pointing back at the organisation. The same nodes appear on every public page, byte-identical. Contradiction between pages is worse than thin data on all of them.
We state, in prose a model can lift, what tapFunnel is and what it is not — including that it is not laboratory glassware, and that the separating funnel has no connection to the company. This felt absurd to write. It also worked, because it hands the model exactly the sentence it needs to resolve the ambiguity, and no other source was going to supply it.
The harder half. Old positioning does not live only in the copy you rewrite. Ours was still encoded in a JavaScript file serving demo client data, in a process page describing a service we no longer sell, in form field names, and in metadata nobody re-reads. A public JS file is crawlable regardless of what the page’s robots meta says. If you reposition, audit the assets, not just the prose.
Self-description has a ceiling. A model weighing who you are wants the claim confirmed somewhere it already trusts — a company profile with real activity, a registration record, a professional profile for the founder that resolves. This is the slowest part and it does not substitute for the first three.
| Check | What good looks like |
|---|---|
| Name consistency | One spelling, one capitalisation, everywhere — site, profiles, registrations, bylines |
Stable @id | Organization and Person nodes with fixed identifiers, referenced not repeated |
| Cross-page consistency | The same entity nodes on every page, identical |
| Disambiguation | A plain-language statement of what you are not, where a collision exists |
| Stale signals | No old positioning in JS, forms, metadata or process pages |
| Corroboration | At least one trusted third-party source confirming the basics |
If you have a generic, homographic, or recently changed name, this is likely a larger share of your problem than your content is — and it is the one nobody tells you to check.
Every figure above is linked to the page that published it. Where a number is self-reported by the company that benefited from it, this post says so.
It is the work of making a model confident which specific organisation your name refers to when that name collides with something else. Where the signal is ambiguous, an assistant will describe the better-attested entity, blend both, or state your facts without naming you at all.
For entity resolution, yes — more than it does for traditional rich results. Organization and Person nodes with stable @id identifiers, referenced consistently across every page, are how a model ties scattered claims to one identity. Contradiction between pages is worse than thin data on all of them.
Old positioning is usually still encoded in places that do not get rewritten with the copy: JavaScript files serving demo or client data, process pages describing discontinued services, form field names and metadata. Public JS is crawlable regardless of a page's robots meta, so audit the assets, not just the prose.
Rarely. Publishing more pages about yourself does not resolve ambiguity if a competing meaning has more corroboration. You need stable identifiers, an explicit plain-language statement of what you are not, removal of contradicting signals, and at least one trusted third-party source confirming the basics.
