Entities, schema and RAG: a practical evidence map

By Sumith Parambat DamodaranPublished in TechnologyOctober 11, 20266 min read

An entity map helps a team state who it is, what its products do and which evidence supports those relationships. Schema can express some of those facts in a recognised vocabulary. Neither replaces a clear page or guarantees that an assistant will retrieve, cite or recommend the brand.

Original diagram showing a decision leading to evidence, ownership and a repeatable check

Original illustration of the workflow proposed in this article; it is not a workshop slide or measured result.

Why I added an evidence map to the backlog

Myriam Jessier’s Fundamentals deck introduces entity maps as a way to make brand facts coherent. Dixon Jones’s conference session on entity maps and Judith Lewis’s session on schema and RAG gave the same problem a technical angle: scattered claims need explicit relationships and evidence.

My practical application is an evidence map for the editorial team. The map comes before choosing a special file format. A team can maintain it in a worksheet or a CMS model while improving the public pages that readers and retrieval systems can actually find.

Describe relationships with verbs and boundaries

For the fictional StudioLedger product, the map would say that the company publishes StudioLedger, StudioLedger supports a documented rescheduling workflow, and that workflow applies to a named payment provider. Each statement points to an authoritative page and has a review owner.

Compare “StudioLedger — payments — flexible” with “StudioLedger transfers an existing payment when a booking moves within the same price band, under the provider conditions documented on the rescheduling page.” The second statement is more useful because the relationship and limits are explicit.

The example is fictional. For real claims, the evidence must exist before the relationship is published. A structured assertion without evidence simply gives an unsupported claim a tidier shape.

A small map can expose large contradictions

I would begin with ten important facts: legal and trading names, product names, intended users, core capabilities, supported integrations, availability, exclusions, evidence pages, authors and review ownership. That is my proposed starter scope, not a standard required by a search engine.

Check where those facts occur on the website. If the homepage implies a capability that documentation excludes, fix the disagreement. If the company and product share a name, explain the relationship. If a capability has changed, identify which comparison pages still describe the old version.

Independent sources may tell a different story. Record those differences separately. A first-party map cannot control external reviews or prove that the rest of the web accepts the company’s claims.

Use schema for supported facts

Choose structured data that accurately represents visible content and the relevant page type. Validate the syntax, then check the meaning. A valid object can still contain an incorrect organisation relationship, outdated offer or unsupported claim.

Google’s guidelines require structured data to represent the page content accurately. Its generative AI guidance says there is no special schema required for those experiences. That makes schema a useful consistency and search feature task, rather than evidence of an automatic GEO uplift.

An experimental entitymap.json or llms.txt file may have a use in a particular service. I would ask which consumer uses it, how updates are handled and what the test measures before promising value. Google explicitly says it does not use special AI text files for Search visibility.

RAG adds a source-selection question

The Advanced reference deck explains RAG as retrieving external information to help form an answer. That model suggests useful investigations: is the authoritative page accessible, is the relevant fact present, and does the displayed citation support the answer?

It does not imply that every assistant has the same retrieval pipeline. A crawler log, a model’s explanation or a successful exact-snippet query cannot establish all the steps inside a closed system. Treat those as observations and combine them with the exposed sources and platform documentation.

My first test

Pick one ambiguous capability, correct its authoritative page and make its relationship to the product explicit. Update applicable structured data to match. Record the before-and-after pages and dates, then repeat factual questions under stable conditions.

Review whether a reader can identify the limitation and whether sampled answers preserve it. Keep citation changes separate from accuracy changes. If the result is inconclusive, the team still gains a clearer source of truth and a better maintained page.

From an entity list to a useful relationship

“StudioLedger, payments, rescheduling” is a list of topics. “StudioLedger supports payment transfer during rescheduling under the documented provider conditions” is a relationship somebody can check.

Subject	Relationship	Object or condition	Evidence and owner
StudioLedger	supports	Payment transfer during rescheduling	Approved workflow; product owner
Payment transfer	requires	Supported provider and price conditions	Provider policy; documentation owner
Comparison page	describes	The same supported workflow	Page review; content owner

All rows are fictional. In a real map, a missing evidence field is an unresolved assertion, not an invitation to invent a source. A changed capability should trigger review of its dependent pages.

Schema can then describe applicable, visible facts. It should not silently turn an uncertain relationship into a public assertion. The claim maintenance workflow explains how to keep the relationships current, while the technical access audit checks that the underlying source can be retrieved.

Sources and attribution

Myriam Jessier, Fundamentals of GEO, supplied deck pages 13–16, 56 and 81–82.
Dixon Jones, Entity Maps: Brief AI Before It Briefs Itself, BrightonSEO 8 October, source photos IMG_3107–IMG_3109; Judith Lewis, Schema in the AI Era, photos IMG_3113–IMG_3114. Speaker concepts are paraphrased.
Charlie Norledge and Petar Jovetic, Advanced GEO & AI Optimisation, reference deck pages 41–44. Reviewed after the event; Advanced course attendance is not claimed.
Google: structured data policies and generative AI optimization guide, reviewed 11 October 2026. The evidence map and test are my original proposed application.