Everything sold as entity optimization rests on one 2012 blog post. It was about a box on the search results page. The one piece of real evidence points somewhere much smaller, and much more useful. And much cheaper.
The entire vendor record is four lines long
One engine has published guidance on how to name entities in your content. It runs to four lines. Here they are in full.
"Define Entities Clearly and Consistently. Use clear and consistent naming for people, organizations, products, and locations. Avoid ambiguous references. Clear entity definition improves grounding visibility and citation accuracy."
That is the whole documented case: twenty-eight words.
Google's position is stranger. Its AI features documentation says there are "no additional requirements to appear in AI Overviews or AI Mode, nor other special optimizations necessary." The word entity does not appear on that page at all.
Google uses the word disambiguate in exactly one place. Its Organization structured data documentation, twice in one sentence pair. Look at what it names: Not Wikipedia. Not sameAs. It names iso6523 and naics.
The boring ones. The two sections after it are worth noticing.
Section 17 says focus each URL on a single topic. Section 18 says surface key information early. Same idea, twice.
Chapter 5 already spent those two. This chapter will not re-argue them. What matters is the pattern: everything Bing publishes about entities is about being legible, and none of it is about being important.
Legible, not important. Your invoice probably says otherwise.
So the whole doctrine rests on one sentence: from the smaller engine, about naming things consistently.
Where did the rest of it come from, and who is billing you for it? Somebody is. Do you know who?
What an entity is inside the machine
One paper opened the box. Almost nobody in this field has read it.
Has anyone sent it to you?
Van Dort and Heuss, University of Amsterdam, at ECIR 2026. They took an open model apart to find out what decides whether it cites a document. Literally apart.
Their finding, verbatim: citation decisions "rely heavily on shallow heuristics such as entity co-reference matching." Now the mechanism, because it is the useful part. Shallow is their word, not ours.
An MLP at layer zero performs what they call "entity enrichment." It acts on the queried entity token. On the first place it appears in the document. That enriched representation then reaches the second occurrence of the same entity, in the question.
Same string, twice.
Their words: the activation carries "an internal flag for cross-context identity." A flag. Not an understanding.
Read that again. The model marks a string in your page as being the same thing as a string in the question. And that mark is part of what makes it cite you.
They proved it by intervening, in both directions. Amplify the pathway and citation recovery "exceeded 90%." Suppress it and 69% of spurious citations disappear.
Now the limits, and they are real: one model, Llama 3.1 at 8 billion parameters. One method. One adapted dataset. The suppression result is nine cases out of thirteen. Nobody has shown that GPT-5 or Gemini works this way.
Nobody can, from outside.
So say the licensed version. In at least one open model, the circuit that decides whether to cite a document starts by matching your name in the page against the name in the question.
Not your meaning. Your string.
Somebody is about to read that as a license to stuff the brand name into every sentence. It is not one.
The mechanism acts on the entity where it first appears in the document. A match, not a count.
Nothing in the paper rewards repetition.
Chapter 1 already showed you where that road goes. In the founding GEO paper, keyword stuffing scored below the baseline it was meant to beat.
A second team found the uncomfortable half of the same story. Wallat and colleagues, at ICTIR 2025, moved cited statements into documents the model had never cited. Then counted the citations.
Where the model had judged the document relevant, 57% of citations were unfaithful. Where the document was pulled at random, 12%.
Put the two together and you get an unglamorous conclusion. Citation is substantially surface-driven and substantially post-hoc.
Good news for anyone whose name is unambiguous. Bad news for anyone who assumed being cited meant being understood. It does not.
Van Dort and Heuss put the consequence more sharply than we would. If citations come from matching names rather than "genuine engagement with document content," then RAG systems "offer only an illusion of verifiability." Their phrase.
One more number from the Amsterdam paper, because it keeps the finding honest. Here it is.
On a harder multi-document dataset, the baseline rate of strictly correct citation was 0.001. Amplification moved it to 0.024.
A gain of more than twenty times, and still almost nothing.
So the mechanism is real. The machine built on it is not good yet. Both are true at once. A chapter printing only the first would be selling you something.
So here is the second.
What happens when the machine cannot tell
If citation runs partly on name matching, the obvious question follows. What happens when one name has two owners?
One study went at it directly. Sedova and colleagues, in EMNLP 2024 Findings, built a protocol to separate knowing a fact from applying it.
Then they tested six models on 49 ambiguous entities: GPT-4o and Llama 3 70B among them.
Read the entity list first. Apple. Amazon. Nike. Tesla. Cisco. Nokia. Puma. Jaguar.
Every one was chosen to have two readings, and the second reading is always a company. Average accuracy in choosing the correct reading: 85%.
With underspecified prompts, 75%.
Underspecified is the case that matters here. A query carrying only a name is exactly that. There the error rate is one in four.
The direction of the errors is the part to take into a meeting. The models "exhibit biases toward preferred readings."
Preferred means more famous, and in their pairs it is the same thing. The animal reading of Jaguar outdraws the car company on Wikipedia. So does the bird called Penguin, against the publisher.
Which is the wrong direction for a company colliding with something larger. Which is most of them.
And here is the finding, verbatim: "All LLMs prefer the animal and fruit reading over the company interpretation."
So the default resolution of a contested name runs away from the company. Systematically.
Scope it before you quote it. Forty-nine entities is a small sample, the task is closed-book factual questions rather than grounded retrieval, and every brand in it is a household name.
So it is not a measured error rate for your company. It is evidence the failure mode exists. And that it has a direction.
Downhill, away from you.
The experiment that tells you whether this is your problem
One study ran the actual test. Take a retrieval pipeline, bolt entity linking onto it, and measure.
ELERAG added a Wikidata-based entity linking module to a standard dense retrieval stack. Then ran it against two corpora.
On a domain corpus with ambiguous terminology, Exact Match went from 0.522 to 0.565. A gain of 4.3 points.
On general-domain text, the same code went from 0.693 to 0.672. A loss of 2.1 points. Their sentence: "the trend observed in the educational benchmark is sharply reversed." Sit with that for a second, because it is unusual.
Most published results tell you a technique works. This one prints both sides of the boundary. Both signs.
The mechanism is not mysterious. Entity linking resolves a string to a specific thing. Where two things share a string, that resolution is worth something. Where nothing is contested, you added a step that can only misfire.
Hold this chapter to the standard it is about to apply to somebody else. Now, not later.
ELERAG is a system you would run yourself, over your own documents. Which is the objection we raise against graph vendors later in this chapter, against ourselves first.
So take the weaker reading, because it is the honest one. For a company with an unambiguous name the evidence shows no measured benefit, and a 2.1-point loss on one closed corpus. Not a measured cost to your website.
The instruction survives either way, because the instruction is to test before you spend.
Which is why it is diagnostic before it is prescriptive. Test first, then spend.
Separate two things this chapter keeps together everywhere else. Two things.
The naming mechanism is general. Van Dort and Heuss found it operating on every entity, contested or not, so writing your name the way buyers write it is not conditional on anything.
The disambiguation is conditional. That is what ELERAG measures, and where nothing is contested it bought nothing.
So do not ask whether you are an entity. Everything is an entity. Ask the question with a different answer for different companies.
Is your name ambiguous?
The audit is one prompt and costs nothing
There is a free, third-party, reproducible adjudication of who owns a name. It is not a tool anybody sells you.
It is the Wikipedia title structure.
Say your name is a disambiguation page, or redirects somewhere else. That is documented evidence: the string is contested. Not opinion. Not a vendor score. Run it on the names you know and it gets uncomfortable fast:
| Name | What the base title resolves to | Where the company sits |
|---|---|---|
| Bolt | Disambiguation. Three separate companies, plus a fastener, a Disney film, a DC character and a surname | Bolt (company) |
| Stripe | Disambiguation. A 1981 film, a Gremlin, a toothpaste, and two other commercial Stripes | Stripe, Inc. |
| Ramp | Inclined plane | Ramp (company) |
| Notion | Disambiguation. Two different products called Notion, an ancient Greek city, sewing supplies | Notion (productivity software) |
| Perplexity | The information theory measure | Perplexity AI |
| Copilot | First officer, aviation | Microsoft Copilot |
| Anthropic | The company | The base title |
- Fetch the base title. Open
en.wikipedia.org/wiki/<YourName>, with your name exactly as customers type it. Four outcomes, not three. You hold the title. It is a disambiguation page. It redirects to something that is not you. Or there is no article at all, which is the normal case for most companies and means nothing on its own. Record which. - Bound the name list before you start. Your company name, plus the three products carrying the most revenue, plus anything named after a common noun regardless of revenue. Not every SKU. A forty-product portfolio audited exhaustively is a project nobody finishes.
- Score the collision with a number, not a judgment. For each competing entity with a Wikipedia article, pull 30-day pageviews from the Wikimedia REST API. One call each. If you have no article, any rival with one wins by default. If you do, and a rival's pageviews exceed yours by more than an order of magnitude, you are arguing with the training data rather than with a competitor. Note it now: for those, the sentence you write in step 8 is a holding action, and the real fix is the coverage work in Chapter 8.
- Add one prompt to the Chapter 1 baseline. The bare name and nothing else: "what is [your name]". You already run that protocol on four engines across three days, so this costs you twelve extra runs rather than a new project. If you have not run the baseline, run it. This chapter is not a reason to build a second measurement rig.
- Keep the Chapter 1 hygiene, all of it. ChatGPT with search on, Perplexity, Google AI Mode, Claude. Three different days, not three sessions in one afternoon. Signed out where the engine allows it, memory off where it does not, a clean profile rather than an incognito window, and one stated locale. An engine that knows where you work will pass this test for the wrong reason.
- Score each run 1 or 0, on one question. Is the answer about your company? One if it is, zero if it is about something else. An answer that lists both readings scores zero, because a buyer reading it does not know which one you are. An answer about the right company but the wrong product scores one, because the collision resolved. Take the first answer, not the best of three, and do not re-roll a bad one. This is the one place we depart from Chapter 1: the baseline counts two of three per engine, and this question is binary enough to count every run.
- Read it per engine, not pooled. Four columns of three. Three failures on one engine is a corpus problem on that engine and nothing you do on your own site will fix it quickly. Three failures spread across three engines is a naming problem, and that one is yours. Exactly two, in either shape, is a naming problem you should fix cheaply and re-read next quarter before spending more.
- Two failures out of twelve is where we act. Two is ours. Nobody publishes a threshold, these systems move under you between runs, and a single failure on a twelve-run sample is noise. Two or more, in the same engine column or across them, is the point where the disambiguating sentence is worth writing.
- Re-run it at the next quarterly baseline. Same prompt, same engines, same scorer. The Chapter 1 protocol already has a cadence, and this rides on it.
The fix is smaller than the pitch: two sentences.
Bing tells you to use clear and consistent naming and avoid ambiguous references. Van Dort and Heuss tell you why that might work. One sentence each.
The string in your page has to match the string in the question. That is the whole finding.
So write your name the way your buyers write it. Same words. On the page. Every time. Then put the category next to it. First sentence, plain language. Not "the leading platform for financial operations." The words somebody would actually type.
Three details decide whether that sentence works, and all three are boring. Which is on your homepage today?
Use one name. If the legal entity is Northgate Logistics Holdings and everyone says Northgate, use Northgate. Everywhere. No exceptions. Chapter 5 told you not to upgrade your vocabulary. Here that is not advice. It is the mechanism.
Put the category in the same sentence. Not the paragraph below. Chapter 4 explained why: the block boundary you did not author may sit between them.
Name the competing entity, once, if there is one. Not defensively. One clause. It says which of the two you are.
When the collision is a competitor
Everything above assumes your rival for the string is a fruit, a fastener or a film. Often it is not. Often it is a competitor.
Often it is a company in your own category, and there the fix above inverts. It inverts.
Add "expense management company" to a name you share with another expense management company and the string gets more collidable, not less. You just handed the model a second reason to conflate you.
So differentiate on the axis you do not share. Segment. Geography. Deployment model. Price band.
"Meridian is an expense management company for construction firms with fleet fuel spend." That separates on customer. "Meridian is a UK-only expense management company." That separates on geography.
Then name the rival once, in the same paragraph. Let the sentence do the work.
Two honest notes on that. First: nothing in the evidence base measures this case, so the instruction above is reasoning rather than a result.
Second: where the rival is much larger and sells the same thing, the on-page fix will not be enough. That is a coverage problem.
It lives in Chapter 8.
Two cases the mechanism predicts
The first is an acquisition: the training data holds your old name. Your pages hold the new one.
The co-reference match fails on both.
Carry both strings in one sentence for as long as the old name still gets typed. How long is that? Nobody has measured it.
The second is other languages: base titles are per language.
String matching is language-specific by construction.
A clean English title tells you nothing about the German one. Repeat step 1 for every market you sell into, one browser tab each.
Then repeat step 4 in-language where the market matters. The collision set changes with the language, because the matching does.
That is the instruction. Two sentences of work, on the pages where it matters.
Anyone selling you more than that owes you a source. Have you asked for one?
Where the doctrine actually comes from
Chapter 5 traced five writing prescriptions to their origins. Same method here, and the results are worse.
Worse in a specific way. In Chapter 5 the origins were real research, misapplied.
Here one of the five has no origin document at all. A second cites nothing but itself. None.
| The claim | Where it comes from | Does it support the claim? |
|---|---|---|
| "Things, not strings" | A Google blog post from 16 May 2012, announcing the Knowledge Graph | Fourteen years old, and about a search feature |
| "Build an entity home" | A proprietary framework. Its own canonical page dates the coinage to 2015 in one place and 2021 in another | Cites no vendor source, patent or study |
| "Raise your entity salience score" | A field in the Google Cloud Natural Language API response, which Google defines as centrality to that one document's text | Never linked by Google to Search or AI |
| "Check the Knowledge Graph API" | An API Google's own page says is "not suitable for use as a production-critical service" | Never linked by Google to Search eligibility |
| "N-gram consistency" | No origin document found. The nearest patents are IBM's, from 2006, about finding chemical compounds in papers | Unsourced. Bing's four lines say the same thing |
Start with the top row, because it is the ancestor of everything else in the table. Everything.
"Things, not strings" is a real Google sentence. It comes from an announcement on 16 May 2012, introducing the Knowledge Graph.
It is a good sentence. It is also fourteen years old. It describes a feature on a results page, and it predates the transformer paper. Nothing in it says how to write a web page.
So the field took a marketing line about a search feature. Then turned it into a doctrine about generative retrieval. In a period when Google's own documentation says no special optimization is necessary.
Two multipliers travel with these claims. Both deserve naming.
The 40% is from the founding GEO paper at KDD 2024. That study tested nine interventions.
Not one was entity-related. The word entity appears once in the whole paper, and it means small businesses.
Chapter 1 took that paper apart on a different question. This is a second reason to stop quoting it.
So every article citing it in support of entity work is misciting it. Check the next one you are sent. The 7.8x comes from a 2026 study of Olympic athletes.
Twenty-seven of them.
Every athlete the study names has a Wikipedia article. The study publishes neither its roster nor any subject without one. So it observes variation among entities that appear to all have one.
Which means it cannot estimate the effect of getting one. That is not a criticism of the study. It is a criticism of how it is quoted.
The knowledge graph pitch, priced by the people who made it
Somebody will offer to build you a knowledge graph. Two things are worth knowing first.
The first is scope. Everything published on entity graphs in retrieval is about a system you would run yourself, over your own documents. None of it is about how an answer engine reads your website.
The second is that Microsoft Research published GraphRAG, then published a successor that undercuts its own cost case.
On the cheaper successor. Indexing costs are "0.1% of the costs of full GraphRAG", with "more than 700 times lower query cost."
One independent benchmark is harsher, and it needs reading carefully. On single-hop questions the honest gap between plain retrieval and the best graph configuration is under two points. Entity graphs did win on multi-hop questions. By 1.62 points.
Roughly a third of the answer entities did not survive graph construction. On two datasets, 65.8% and 65.5% made it through.
Read that as a data loss figure. You built a graph and it dropped a third of the things the answers needed.
None of which means graph retrieval is worthless. It won the multi-hop case, and multi-hop questions are real.
The pitch and the evidence point at different products. The evidence supports one thing: a retrieval architecture, for one question shape, inside a system you operate. The pitch is that a graph makes Google understand your brand.
Those are not the same claim, and only one of them has a paper behind it.
Wikipedia, priced honestly
The loudest claim in entity marketing is that AI answers run on Wikipedia. True for one engine. Close to false for two others.
| Engine | Wikipedia share of all citations | Rank | What leads instead |
|---|---|---|---|
| ChatGPT | 7.8% | 1st | Nothing close. Reddit is second at 1.8% |
| Google AI Overviews | 0.6% | 8th | Reddit 2.2%, YouTube 1.9%, Quora 1.5%, LinkedIn 1.3% |
| Perplexity | Not in the top ten | Absent | Reddit 6.6%, YouTube 2.0%, Gartner 1.0% |
Now the question a founder actually asks. Can we get a Wikipedia page?
For most companies the answer is no. The reason is structural, not editorial: arithmetic, not gatekeeping.
Wikipedia's notability rule lists the coverage that does not count. Read the qualifier first. It does the work.
The policy excludes "brief announcements, standard notices, and routine coverage" of a list of things.
Funding rounds. Acquisitions. Executive hires. Product launches. Quarterly results. Trade fair appearances. Sponsorships. And this: "inclusion in lists of similar organizations, particularly in 'best of', 'top 100', 'fastest growing' or similar lists."
Read that as the routine coverage of a normal venture-funded company, because that is what it is.
Two escape hatches exist and both are narrow. In-depth independent analysis of an acquisition still counts, because it is not routine.
Where the list itself is notable, the policy names the Fortune 500 and the Michelin Guide, inclusion counts like any other reliable source.
The rule also says: "no company or organization is considered inherently notable." And: "only unpaid sources count." Only unpaid.
Which makes this a Chapter 8 problem, not a Chapter 6 one. Earned coverage is not on-page work.
Wikidata is a different question with a different answer. No comparable bar, and anyone can create an item.
We counted, so you do not have to. Of the items Wikidata types directly as businesses, 22.9% have an English Wikipedia article.
Against the tens of millions of companies that exist, everything Wikidata holds is a rounding error.
No study has measured whether creating a Wikidata item changes anything in any answer engine. Given how trivially creatable they are, the absence of that study is conspicuous.
One more thing about Wikipedia, because it changes how you should think about the whole asset.
The Wikimedia Foundation published its own traffic analysis in October 2025. Correcting for bots built to evade detection, human pageviews fell roughly 8% against 2024.
Their stated belief: the decline "reflects the impact of generative AI and social media on how people seek information." Belief, they say.
Price that carefully. The headline version overstates it. The 8% compares revised 2025 months against unrevised 2024 months. Wikimedia flags that its bot rules changed in between. The attribution to AI is belief rather than demonstration.
But take the shape of it seriously.
The corpus everybody wants into is losing human attention and gaining machine attention. Wikimedia's own line: "almost all large language models train on Wikipedia datasets."
Which makes a Wikipedia article an increasingly odd asset. Fewer people read it, and more machines do.
That is not an argument against wanting one. It is an argument for reading the notability list before anybody bills you for the attempt.
The question this chapter will not answer for you
Every founder who runs the audit and scores badly asks the same thing next. Should we change the name?
We are not going to tell you to. Here is the reasoning, so you can disagree with it properly.
A rename is among the most expensive things a company can do: domains, contracts, trademarks, every piece of collateral, and the compounding you gave up on the old name. All of it, at once.
Against that, this chapter has three things. A mechanism from one 8-billion-parameter model. A 4.3-point retrieval result on a closed corpus. A one-in-four error rate on underspecified prompts, over 49 famous brands.
Nobody has measured the revenue cost of an ambiguous name in AI answers. Nobody has measured it in classic search either.
So the evidence cannot justify a rename. Anyone telling you otherwise is selling a rebrand.
Ask what they sell.
What it can justify is the cheap end. Two sentences per page. A disclaimer clause where the audit came back dirty. Consistency in how the name is written everywhere you control.
The Anthropic row in Table 6.2 shows the only route anybody has been seen to take. That base title did not move because of markup.
It moved because the coverage moved. Yours would too. Which is Chapter 8, and it is a different budget.
The objection this chapter has to answer
"You have told me the mechanism comes from one 8-billion-parameter model, the direct test comes from a research pipeline over closed corpora, and nobody has measured what a real engine does with an ambiguous brand name. So what am I buying?"
Two sentences per page, and one audit. That is genuinely all this chapter asks for.
The disclosure this chapter owes you. It has spent a chapter attacking a field we sell into.
We have sold entity work. We are telling you to stop buying most of it. And if your twelve come back clean, we will tell you that too.
Notice where the money goes when we do. Four times in this chapter, a canceled line item gets routed to Chapter 8.
Chapter 8 is earned coverage, and earned coverage is a bigger engagement than an entity retainer.
That is not a reason to disbelieve the chapter. It is a reason to ask us the question, and to weigh what we say next.
Price it against the alternative. The alternative is a retainer built on a 2012 announcement about a knowledge panel, a salience field from an unrelated Cloud product, and a study that tested nine things, none of which was this.
Now the harder half. The gap is real and we are not going to paper over it.
No published study takes a set of ambiguously named brands, queries production answer engines, and counts the wrong answers. Not from a vendor, not from a university, not from an agency.
Which is strange, because it is cheap and obvious. So why has nobody run it?
So Artifact 6.3 exists to let you run the small version on yourself, and to stop you spending on the basis of somebody else's confidence. There is a second objection, and it is the better one.
"Every engine I care about is grounded. It retrieves my page before it answers. So the ambiguity study, which is closed-book, does not describe my situation at all." That is correct, and it cuts the chapter down rather than through it.
Grounding does reduce the problem. If the retrieval step has already found your page, the model has your category in front of it.
But retrieval is a query-matching step, and Chapter 2 spent a chapter on where those queries come from. You do not write them.
When the fan-out generates a query carrying only your name, the collision is back. Upstream of the grounding you were counting on.
Ours, not a finding. Nobody has published a fan-out carrying a bare brand name, and Google's own worked example is all category queries.
So the honest scope is narrower than the field's. And wider than the objection's. Ambiguity costs you at the point where a query is only a name.
And only there.
If your twelve come back clean, spend nothing on entity optimization this year. When did an agency last tell you that?
What is left
Strip out everything without a source and two things are left. A diagnosis and a sentence. Two things.
The diagnosis: append one prompt to the baseline you already run, and let twelve runs decide whether any of this is your problem.
The sentence: name yourself the way your buyers name you, and put the category next to it. Same words they use.
Everything else on offer here is a 2012 blog post wearing a 2026 invoice.
Say what this chapter is not claiming, because the field's version is so much larger. Much larger.
We are not claiming entities do not matter. We are claiming the part you can act on is small and cheap.
Small because it is two sentences.
Conditional in one part only. Consistent naming is general, on the evidence available. The disambiguating clause is what a clean audit tells you to skip.
And any claim that an unambiguous company gains nothing is our extrapolation from a single negative delta on one closed corpus. Not a measured result about your website.
One thing nobody can price, so we will not pretend to. Nobody has taken a set of ambiguously named brands, asked production engines about them, and counted the wrong answers.
Not one.
Until somebody runs that, your own twelve runs are better evidence than anything you can buy.
One thread stays open, deliberately.
sameAs and @id exist to say this is the same entity as that one, and this chapter has not evaluated either.
Nor has it followed its own best Google finding. Google uses the word disambiguate in one place only. Its Organization markup documentation. And the properties it names there are markup properties.
Which means the strongest evidence in this chapter resolves in the next one. Where else would it?
Chapter 7 is about whether that argument gets read.
- Add one prompt to your Chapter 1 baseline. The bare name, four engines, three days. Under two failures in twelve, spend nothing on entity work.
- Name yourself the way buyers name you. Same string, on the page. In one open model that match is part of the circuit deciding citation.
- Put the category in the same sentence. Plain words a buyer would type, not the positioning line your agency wrote.
- If the collision is a competitor, separate on what you do not share. Segment, geography, price band. The category will not do it.
- Do not buy a Knowledge Graph audit. Google calls that API unsuitable for production-critical use, and has never linked it to anything in Search.
- Treat Wikipedia as earned coverage. Funding, launches, hires and "top 100" lists all fail the notability test as routine coverage.
- Bing Webmaster Guidelines, section 16, "Define Entities Clearly and Consistently." Quoted in full. The article carries no publication or last-updated date, and the page is a JavaScript application whose text is served from a separate content endpoint.
- Google Search Central, AI features documentation, updated 10 December 2025. "No additional requirements to appear in AI Overviews or AI Mode, nor other special optimizations necessary." The word entity does not appear on the page.
- Google Search Central, Organization structured data, updated 15 April 2026. The only Google use of "disambiguate" in this area, twice in one sentence pair, naming iso6523 and naics rather than sameAs.
- Google Knowledge Graph Search API documentation, last updated 26 April 2024. "This API is not suitable for use as a production-critical service. Your product should not form a critical dependence on this API." The successor is a Google Cloud product serving a Cloud-built graph, and Google has never linked presence in it to eligibility in Search or any AI feature.
- Google Cloud Natural Language API, Entity object reference, updated 13 June 2025. Salience is defined as "the importance or centrality of that entity to the entire document text."
- van Dort and Heuss, "How Do LLMs Cite? A Mechanistic Interpretation of Attribution in Retrieval-Augmented Generation," ECIR 2026, LNCS 16485, pages 458 to 473, arXiv:2606.28358. Llama 3.1 8B Instruct only, activation patching, a citation adaptation of PopQA run twice per example, once with a supporting document and once with a distractor. Citation recovery above 90% under amplification, 9 of 13 spurious citations suppressed. On a multi-document dataset the strict correct-citation rate moved from 0.001 to 0.024, more than twentyfold and still almost nothing.
- Wallat, Heuss, de Rijke and Anand, "Correctness is not Faithfulness in Retrieval Augmented Generation Attributions," ICTIR 2025. Cohere Command-R+ over 1,444 questions. Citations were unfaithful in 57% of cases where the statement was moved into a document the model judged relevant but had not cited, and in 12% of cases where the document was chosen at random.
- Granata, Poggi and Mongiovi, "Enhancing Retrieval-Augmented Generation with Entity Linking for Educational Platforms," arXiv:2512.05967. Exact Match 0.522 to 0.565 on a domain corpus with ambiguous terminology, and 0.693 to 0.672 on general-domain text. A research pipeline over closed corpora, not a production engine.
- Sedova, Litschko, Frassinelli, Roth and Plank, "To Know or Not To Know? Analyzing Self-Consistency of Large Language Models under Ambiguity," EMNLP 2024 Findings, arXiv:2407.17125. Six models including GPT-4o and Llama 3 70B. Every one of the 49 entities was selected to carry a company reading alongside another, and the paper reports that "All LLMs prefer the animal and fruit reading over the company interpretation." Average accuracy 85%, falling to 75% under underspecified prompts. Closed-book factual questions rather than grounded retrieval, and every brand in the set is a household name.
- Microsoft Research, "LazyGraphRAG," 25 November 2024. Indexing at "0.1% of the costs of full GraphRAG" and "more than 700 times lower query cost." The same post retains a defense of the full index for uses beyond question answering, so this is a cheaper successor rather than a withdrawal.
- Controlled comparison of retrieval against entity-graph retrieval, arXiv:2502.11371. Single-hop 64.78 for plain retrieval against 34.28 for the triplets-only graph and 63.01 for the best graph configuration. Multi-hop 61.66 against 60.04. And 65.8% and 65.5% of answer entities surviving graph construction on two datasets.
- Aggarwal, Murahari, Rajpurohit, Kalyan, Narasimhan and Deshpande, "GEO: Generative Engine Optimization," KDD 2024, arXiv:2311.09735. Nine interventions tested, none entity-related. The word entity appears once, meaning small businesses.
- Profound, "AI Platform Citation Patterns," published 5 June 2025 and updated August 2025. 680 million citations, August 2024 to June 2025. A vendor that sells AI visibility software, sampling prompts its customers care about.
- Pew Research Center, 22 July 2025. 900 US adults, 68,879 searches in March 2025, of which 12,593 produced an AI summary. Wikipedia, YouTube and Reddit together were 15% of AI summary sources against 17% of standard results, with Wikipedia somewhat more common in AI summaries and YouTube somewhat less.
- Seer Interactive, "The GEO Olympics Study," 27 April 2026. 231,347 responses across 27 tracked athletes. The study publishes neither its roster nor any selection criteria, and every athlete it names has a Wikipedia article. The 7.8x figure compares athletes carrying three signal layers against those that did not, and the rho of 0.810 is a correlation with seven-day Wikipedia pageviews.
- Wikimedia Foundation, "New user trends on Wikipedia," 17 October 2025. Human pageviews down roughly 8% against the same months in 2024, after reclassifying bot traffic built to evade detection. The comparison is revised 2025 months against unrevised 2024 months, and the Foundation states its bot rules changed in between, so the attribution to generative AI is its stated belief rather than a demonstrated result. Also "almost all large language models train on Wikipedia datasets."
- Wikimedia REST API, per-article pageview endpoint, used in Artifact 6.3 step 3 as a mechanical fame proxy. Free, no key, one call per article.
- English Wikipedia, "Notability (organizations and companies)," fetched 19 August 2026. The excluded categories are headed "brief announcements, standard notices, and routine coverage," and the list carries an exception where the list itself is notable, naming the Fortune 500 and the Michelin Guide. Also "no company or organization is considered inherently notable" and "only unpaid sources count."
- Wikidata Query Service, counts run 19 August 2026 and reproducible. 263,096 items directly typed as business, of which 60,188 have an English Wikipedia article, and 765,262 once every subclass is included.
- Wikipedia base titles and disambiguation pages for Bolt, Stripe, Ramp, Notion, Perplexity, Copilot and Anthropic, fetched 19 August 2026 from the English Wikipedia REST and raw wikitext endpoints.