Entity Architecture: Making Your Brand a Thing Models Can Name

Entity architecture is how you make your brand a named thing — one Organization, the people who stand for it, and the products or services you actually sell — so retrieval systems and chat models can say your name instead of a category hedge. If “Acme” could be your studio, a rival in another state, or a cartoon crate, the model will recommend whoever has the cleaner identity packet.

This is not a lecture on academic knowledge-graph theory. It is the identity layer of the Answer Engine Optimization playbook: make Organization, Person, and Product agree everywhere a crawler or a model can look. I have been SEO certified since 2021. The AEO version of that work is still a fact sheet you can defend.

The short answer

• Pick one public name, one type, and one set of attributes. Repeat them on About, schema, and the profiles you control
• Wire Organization, Person, and Product to each other with real relationships (founder, worksFor, brand, makesOffer)
• Use sameAs only for pages that unambiguously are you
• Google’s Knowledge Graph is a database of facts about people, places, and things — you do not file an application to join it (Google: How the Knowledge Graph works)
• Re-test “What is [Brand]?” after every rename. Fix the sources that disagree, not the homepage copy alone

What is entity architecture for AI search?

Entity architecture is the deliberate design of a stable identity packet: preferred name, type, attributes, relationships, and evidence URLs that agree with each other. Classic “entity SEO” meant lining that packet up with Google’s Knowledge Graph. AI search adds a second job: the same packet has to survive compression in chat answers that sample the open web.

Google’s 2012 launch line still names the problem: search moved from matching strings to understanding things, not strings. schema.org is the shared vocabulary for declaring those things. The Knowledge Graph Search API returns entities using schema.org types and JSON-LD. Your job is not to “build a graph.” Your job is to stop publishing three incompatible versions of the same company.

Piece	What it is	What “done” looks like
Preferred name	The public string you want recited	Homepage H1, About, schema name, LinkedIn, and invoices agree
Type	Organization, Person, Product, Service, LocalBusiness	The most specific schema.org type that is true
Attributes	Founded, HQ, category, offers	One fact sheet; no competing years or cities
Relationships	founder, worksFor, brand, parentOrganization	Prose and JSON-LD tell the same story
Evidence	url + sameAs	Only pages that are unambiguously this entity

An entity, for operators, is not a triple store. It is a packet a model can name without hedging.

• You can write the packet on one page without footnotes that contradict it
• A stranger can tell you apart from the nearest name collision
• Sales, legal, and marketing use the same public name in the same week

A keyword strategy tells pages what to rank for. Entity architecture tells machines who you are.

Why do models need Organization, Person, and Product to agree?

Generative systems compress. Compression prefers nodes with clear labels and consistent neighbors. When the company name, the founder bio, and the product page disagree, the model has three candidates and no reason to pick yours. That is how you become “a digital studio in Austin” instead of a name.

Google’s Organization markup guide is explicit about the first job of structured data here: help systems understand administrative details and disambiguate your organization. Chat products do not publish an equivalent spec. They still inherit the same failure: two HQs, two founding years, two SKUs.

Symptom	What the model did	Usual source of the mess
Category hedge	Used your industry, not your name	No stable “what we do” sentence; schema description drifts
Name merge	Blended you with a same-named company	Missing disambiguation; shared sameAs or squatters
SKU swap	Recited a competitor’s product	Offer pages rotate synonyms; no Product URL
Founder error	Attached the wrong prior company	Person bios disagree with Organization founder
Ghost offer	Sold a retired package	Footer logos and old PDFs still name it

Those are identity failures, not random insults. The fix is agreement across three nodes, not a longer About essay.

• Organization name matches the Person’s worksFor / founder target
• Product or Service name matches what sales says on calls
• No third “platform” synonym lives only in ads

If the three nodes disagree, the model will pick the loudest wrong source.

What belongs on the Organization node?

The Organization node is the company as a thing. schema.org defines Organization as a type with name, url, logo, description, founder, legalName, and sameAs among the properties that matter for identity. Google’s Search Central guide adds the operator constraint: put this block on the home page or a single About page, not on every URL. Use the most specific subtype that is true — OnlineStore, a LocalBusiness subtype, and so on.

Google lists sameAs as a recommended Organization property: a URL on another site with more information about you, and you may supply more than one. It also recommends legalName when the registered name differs from the public name, plus foundingDate, address, and identifiers such as iso6523Code when they apply. Those identifiers exist to disambiguate, not to decorate JSON-LD.

Property	Use it for	Do not use it for
name	The public brand customers say out loud	A seasonal campaign line
legalName	The registered entity, if different	Alternating with name in H1s
alternateName	Real aliases people already search	Every slogan you retired
url	Canonical homepage	A campaign landing page that will die
logo	The mark you want in panels and answers	A wordmark that only exists in a pitch deck
description	The same sentence as About	A second, “punchier” version
sameAs	Profiles that are this organization	Wikipedia articles about someone else
founder	The real Person node	A “team” blob with no URLs

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Studio",
  "legalName": "Example Studio LLC",
  "url": "https://www.example.com",
  "logo": "https://www.example.com/logo.png",
  "description": "Example Studio builds production automations and custom brand sites.",
  "founder": { "@id": "https://www.example.com/about#person" },
  "sameAs": [
    "https://www.linkedin.com/company/example-studio"
  ]
}

That block is worthless if About, the footer, and LinkedIn tell a different story. Markup is a mirror. It is not a patch.

• Homepage, About, and Organization schema share one name and one description
• logo meets Google’s crawlable-image rules (112×112px minimum, indexable URL)
• You used a subtype only when it is true — not LocalBusiness for a company with no location

One Organization node. One public name. Everything else is a relationship or an alias you can defend.

When does the Person node matter?

The Person node matters when trust is personal — founder-led studios, expert practices, anyone whose name shows up in a sales conversation. schema.org Person is the type. The properties that keep you from merging with a namesake are name, jobTitle, worksFor, sameAs, and a stable profile URL. Organization points back with founder or a similar relation. If those arrows disagree, chat answers invent a prior employer.

A Person page is not a resume dump. It is the public record of spelling, role, and affiliation. The Knowledge Graph Search API can restrict results to Person as defined by schema.org. That is the same type you should be emitting, not a blog byline with a different middle initial.

Person field	Required for naming	Failure if sloppy
name	Yes — one spelling	Models split you into two people
jobTitle	Yes — current role	Stale titles from an old About
worksFor / founder	Yes — link the Organization @id	You work at a company that does not exist in markup
url	Yes — a real bio page	Only a LinkedIn URL, and it drifts
sameAs	Profiles you control	A Wikipedia page that is mostly about someone else
Headshot	Optional, but keep one canonical file	Five crops with five filenames become five people

• Founder spelling matches Organization copy and the LinkedIn personal profile
• Role titles on the site match the Person schema jobTitle
• The Person page links to the company; the company names the person
• Old employers are dated, not implied as current

If the brand is the product and no public expert exists, skip the Person node. Do not invent a spokesperson entity to look complete.

A founder with three bios is three entities. Pick one.

How should Product and Service names stay stable?

Models recite whatever name they can resolve. If sales sells “GrowthOS” and marketing says “our platform,” you do not have a Product. You have a synonym cloud. schema.org Product is the type for a named SKU or packaged offering. Service is the type for work you perform. Both inherit sameAs from Thing. Both need a URL that will still exist next quarter.

Google’s merchant Product markup is a separate rich-result program with its own required fields. You do not need that program to give an offer a name. You do need a page whose name matches the spoken name, plus brand or provider pointing at the Organization.

You sell	schema.org type	Name rule	URL rule
Packaged service	Service (or Offer)	One public name; list aliases under alternateName	A durable service page, not a PDF
Software SKU	Product / SoftwareApplication	SKU and marketing name mapped	Product URL + “formerly” if renamed
Flagship method	Named Service or CreativeWork	Definition page, not a vibe word	One canonical explainer
Public cohort	Event when scheduled	Event name ≠ company name	Date-stamped URL

Mapping offers to types is a language decision first:

1. Write the name customers already say.
2. Put that name on a URL you will keep.
3. Mark it up as Product or Service.
4. Point brand / provider at the Organization.
5. Ban unofficial synonyms in ads and decks for 90 days.

• Every commercial offer in the price list has a public name
• That name appears in the H1, the schema name, and the proposal template
• Retired offers redirect or say “formerly” — they do not linger in the footer

If the offer cannot survive a name freeze, it is not an entity yet. It is a slide.

What does sameAs actually do?

sameAs is identity equivalence. schema.org’s definition is the whole rule: a URL of a reference page that unambiguously indicates the item’s identity — Wikipedia, Wikidata, or an official site. Google’s Organization guide repeats the operator version: a page on another website with more information about your organization, and you may list several. It is not a backlink field. It is not a “see also.”

schema.org reports sameAs in use on 10M+ domains from Google’s web index as of July 2026. Volume is not quality. A sameAs array that points at a parked Twitter handle, a sold LinkedIn page, or a Wikipedia article that is primarily about someone else teaches the graph the wrong merge.

Link target	Safe sameAs?	Why
LinkedIn company page you admin	Yes	Official profile of this Organization
Personal LinkedIn of the founder	On the Person, not the Organization	Different entity
Wikidata item that is this org	Yes, if the item is actually you	Machine-readable identity
Wikipedia article mostly about a namesake	No	You just merged with them
Crunchbase / GitHub / YouTube you control	Yes	Extra evidence, keep the list short
Industry directory with the wrong category	No	You imported a lie
Partner logo page	No	Partnership is not identity

Hygiene rules that prevent self-owns:

• Only link profiles you control or that are unambiguously about you

• Prefer HTTPS canonical profile URLs — no tracking wrappers

• Delete or claim dead handles; unclaimed slots become impostor entities

• Do not reuse the same sameAs URL across two brands in a group

• Ten solid links beat forty junk directories

• Every sameAs URL loads as the entity you claim

• Organization and Person lists do not share profile URLs

• You can explain each link in one sentence

sameAs says “this is the same thing.” If it is not, you forged a merge.

How do you build entity presence without a knowledge-graph project?

You do not need a graph database, a Wikidata campaign, or a consultant who says “ontology.” You need a fact sheet, aligned owned properties, and a short sameAs list. Google’s Knowledge Graph is assembled from public sources, licensed data, and suggestions from people who claimed a panel. You influence it by making the public record boringly consistent. Chat models sample that same record.

1. Inventory conflicts

Search the legal name, trade name, and product names. Write down every founding year, HQ city, and tagline variant. Semrush and similar tools help you see branded SERPs and referring domains. Ask ChatGPT “What is [Brand]?” and capture the errors. Do not argue with the model. Screenshot the sources it is echoing.

2. Pick canonical attributes

Write a one-page fact sheet. Resolve disputes with primary sources — articles of incorporation, the real HQ, current product names. Retire zombie brand names in public copy. If legal and marketing disagree, marketing loses until legal updates the record.

3. Align owned properties

Homepage, About, footer, and Organization schema should repeat the same core sentences. Google recommends the Organization block on one home or About URL. That is the entity home. Other pages can mention the brand; they should not invent a second description.

4. Wire sameAs and profiles

Update LinkedIn, directories, and partner pages so descriptions match the fact sheet. Broken or parked social profiles dilute the graph — delete or claim them. Keep the sameAs list short.

5. Earn disambiguation where needed

If another company shares your name, say so in plain language on About. Wikidata only when you meet notability — a clearly identifiable entity with serious public references, a Wikimedia sitelink, or a structural need. Never spam an item into existence.

6. Re-test AI descriptions

Monthly, ask more than one product who you are and what you sell. Log drift against the fact sheet. Fix the URL that taught the wrong fact.

Week	Job	Time box
1	Brand-name prompts in two AI products + Google	30 min
2	LinkedIn, GBP if local, one industry directory	30 min
3	Schema / About only if a fact changed	30 min
4	Idle unless you renamed or launched something	—

That cadence beats an annual “rebrand the graph” project. Entities drift in drips. Catch drips.

• Fact sheet approved by someone who can bind the company
• About + schema + top five profiles aligned
• Conflicting directories flagged
• Identity prompts live on the brand panel

When you hire help, hand them the registry table and the AI answer log. Those two artifacts beat a slide deck.

What breaks when names collide or drift?

The expensive failure is not “we lack a knowledge panel.” It is a model that names the wrong company, the wrong city, or a product you sunset last year. Google may remove Knowledge Graph information that is demonstrably false or outdated when evidence is strong. Chat products have no equivalent ticket. They keep reciting the leftover PDF until the leftover PDF dies.

Failure	What it costs	What you do instead
Rotating taglines every quarter	The “what we do” sentence never stabilizes	Keep one category sentence; rotate campaigns underneath it
sameAs to the wrong Wikipedia	You merge with a namesake	Remove the link; add a disambiguation sentence
Contradictory founder dates	Person node splits or attaches to the wrong firm	One bio, dated employers, matching founder
Product rename, no “formerly”	Models sell the ghost SKU	Alias on the product page for 6–12 months + 301s
Junk directories with wrong categories	Retrieval picks the directory over About	Claim, correct, or document why you ignore them
Footer logos from dead mergers	AI invents product lines you no longer sell	Give each leftover brand a sentence or delete it

Name collisions are the sharp version. Two companies share a string. The national franchise has more pages. Your regional consultancy becomes “the tax prep chain” in answers. The fix is not a press release. It is a longer public name, a disambiguation sentence, and off-site listings that use the longer descriptor.

• You know the nearest name collision and have a sentence that forks the road
• Retired SKUs have a “formerly” note or a 301
• Partner logo walls that outlived the partnership are archived

Drift is quiet. Collisions are loud. Both are identity bugs.

How do you disambiguate a shared name?

Disambiguation is a plain-language fork, not a legal essay. schema.org even has disambiguatingDescription for this job — a short clause that tells machines which thing you are. Put the human version high on About. Repeat it wherever a model might retrieve a second entity with your string.

Spurlock Studios is an AI automation and web design studio founded by William Spurlock. Not affiliated with [Other Entity] in [Place].

That sentence is the product. Markup can echo it. A knowledge panel, if one exists, is a later Google card — see knowledge panels and model memory for the panel-versus-chat split. You can be nameable in chat with no panel at all.

Surface	What to publish	What not to publish
About (high)	One “not affiliated” sentence + your type	A 400-word history of the other company
Organization schema	disambiguatingDescription + correct address / areaServed	A sameAs to the other company’s Wikipedia
Person page	Your role and this Organization	A bio that could fit the namesake
Directories	Longer descriptor (“fractional CFO for manufacturers”)	The short collision string alone
Wikidata	Only if the item is you and sourced	A drive-by edit on the other item

Procedure when you discover a collision:

1. Confirm the other entity is real and still active.
2. Write the fork sentence with place, category, or founder — whichever splits cleanly.
3. Ship it on About the same day.
4. Update Organization description / disambiguatingDescription.
5. Fix the three directories most likely to be retrieved.
6. Re-run the brand prompt. If the merge persists, the leftover source is still live — find it.

Wikidata is optional. An item is acceptable only if it meets at least one notability test: a valid Wikimedia sitelink, a clearly identifiable entity with serious public references, or a structural need. Bad Wikidata is worse than none.

The fork has to be fetchable. A Slack note does not disambiguate you.

What happens when you rename a product?

A rename without an alias is how ChatGPT keeps selling the ghost SKU. Models have training residue and retrieval. Residue lags. Retrieval will keep finding the old name on PDFs, app-store listings, and a comparison post from 2024. Your job is to make the new name the loudest true string and keep the old name as a labeled alias until answers stabilize.

schema.org gives you name and alternateName. Use both. Google’s Organization guide treats alternateName as another common name the organization goes by. The same idea applies to Product and Service. Do not delete the old string from the internet. Point it at the new one.

1. Choose the new public name. Freeze unofficial aliases.
2. Update UI, docs, and marketing in the same week.
3. Add “formerly known as [Old]” on the product page for 6–12 months.
4. 301 old marketing URLs to the new product URL.
5. Update schema name / alternateName and the Organization makesOffer pointer.
6. Notify the directories and listings that still rank for the old name.
7. Add rename prompts to the AI panel (“What happened to [Old]?”) until answers stabilize.

Day	Owned	Off-site	Test
0	Fact sheet + product H1 + schema	—	Screenshot current AI answers
7	301s live; docs swapped	LinkedIn / app listings	“What is [New]?” and “What is [Old]?”
30	Footer and nav cleaned	Top five directories	Ghost SKU still recited? find the URL
90	Keep “formerly” if residue remains	Analyst / partner one-pagers	Drop the alias only when answers hold

Skipping the “formerly” line is the usual self-own. The model is not stubborn. You hid the mapping.

• Old name 301s to the new product URL
• alternateName carries the old string
• Prompt panel includes the rename question

A rename is an entity event. Treat it like a move, not a headline.

How should local and multi-entity brands split nodes?

One legal group is not one entity. A studio with a DBA, a second country entity, and three service brands will look like five companies unless you say how they nest. schema.org gives you parentOrganization, subOrganization, and department. Google’s LocalBusiness guide says to define each location as its own LocalBusiness and to use the most specific subtype. Google’s Organization guide says the same for local subtypes: do not mark a restaurant as a generic Organization and hope.

DBA names confuse graphs when the legal entity and the trade dress swap in H1s. Lead with the name customers recognize. Mention the legal entity once where the law requires it. Do not alternate at random.

Situation	Node split	Relationship to write in prose and markup
One brand, one HQ	Single Organization	—
Visitable or service-area locations	Organization + LocalBusiness per location	Parent / department; NAP unique per location
DBA vs legal name	One Organization	name = trade; legalName = registered
Two countries, two companies	Two Organization nodes	parentOrganization / subOrganization
Multi-brand group	One Organization per brand	Never share sameAs across brands
Agency inheriting merger logos	Page or delete each leftover	Ghost footer brands become invented SKUs

• Invoices, contracts, and the website do not imply two unrelated companies
• Each location has its own NAP and LocalBusiness subtype
• Each brand in a group has its own sameAs list
• Ended partnerships are archived, not left as logo-wall implications

If you cannot draw the tree on a whiteboard, models cannot either.

How do you score whether models can name you?

A knowledge panel is one visible Google outcome. Google is clear that panels appear when automated systems decide there is enough information, and that display is not something they will influence on request. Entity architecture is the consistency underneath — the same consistency that feeds chat answers and Overviews. Score the packet, not the screenshot.

Keep a registry. Notion or a repo table is enough: entity_id | type | preferred_name | url | sameAs | owner | last_reviewed. That registry feeds schema generation and stops freestyle CMS edits from inventing a second brand. Google’s structured-data intro still prefers JSON-LD as the format. Emit one Organization block, one Person block when trust is personal, and one Product or Service block per named offer. Nest relationships. Do not paste three disconnected blobs that never share an @id.

Node	Owner	Touches	Review trigger
Organization	Founder or ops	About, footer, schema, LinkedIn company	Legal name change, HQ move
Person	The person named	Bio page, bylines, personal LinkedIn	Role change
Product / Service	Whoever owns the offer	Product URL, proposals, ads	Rename, sunset, new package

If two people can edit name without talking, you will get a second brand. That is the operating model.

Rate 1–5 monthly:

Signal	1	3	5
Name consistency across top 10 sources	Three public names	Two, with a known alias	One name + documented aliases
Attribute consistency (founded, HQ, category)	Open disputes	One leftover directory	Fact sheet matches retrieval
Profile completeness	Dead handles in sameAs	Top three profiles clean	Short, live sameAs list
Disambiguation clarity	Collision unanswered	Sentence exists, not fetched	Fork is on About and directories
AI brand-query accuracy	Category hedge or merge	Named, with one wrong attribute	Named, typed, offer-correct

Anything below 3 becomes a sprint item. Do not wait for a rebrand to notice drift.

Quarterly agenda (45 minutes):

1. Diff AI brand answers vs the fact sheet (15)
2. Check top 10 profile descriptions (15)
3. Review the registry for renamed offers (10)
4. Assign cleanup tickets (5)

• Registry has an owner
• Brand prompt panel includes identity questions
• Last review date is this quarter
• You are not using “we need a panel” as a substitute for “our facts disagree”

Retrieval can move in weeks after source cleanup. Weight-level residue can lag. Score accuracy separately from “a card appeared.”

FAQ

What is entity SEO?

Entity SEO is optimizing how search and knowledge systems understand your brand as a distinct real-world thing — with consistent names, types, attributes, and relationships — rather than only optimizing pages for keywords. In 2026 that still includes Google’s Knowledge Graph, which Google describes as a database of facts about people, places, and things. The practical test is whether a model can name your Organization, Person, and Product without hedging or merging you with a namesake.

How do I build entity presence for AI search?

Resolve canonical facts on a one-page sheet, mark up Organization, Person, and Product so they point at each other, align the profiles you control via sameAs, and re-test AI answers for identity errors. Put Organization structured data on the home or About page, the way Google’s Organization guide recommends. Pair the identity work with the broader AEO playbook.

Do I need Wikidata?

Only if you can meet Wikidata’s notability tests — a valid Wikimedia sitelink, a clearly identifiable entity with serious public references, or a structural need. Many brands get usable AI descriptions from owned pages plus niche press without a Wikidata item. A thin or wrong item is worse than none, because sameAs will advertise the mistake.

Is entity architecture the same as a knowledge panel?

No. A knowledge panel is one automatically generated Google Search card. Entity architecture is the underlying Organization / Person / Product consistency that also feeds chat answers and Overviews. Google creates panels when its systems decide enough information exists; you cannot request one. More on that split in brand knowledge panels and AI.

How does this relate to citations?

Models cite sources. They name entities. Weak entities get omitted even when a page ranks, because the system cannot tell which thing the page is about. Strong entities with weak pages still struggle — there is nothing citeable to attach the name to. You need a resolvable identity and pages worth retrieving.

How often should we audit entities?

After every rebrand, product rename, office move, or merger — and on a quarterly cadence otherwise. Include AI identity prompts in that review, and treat anything below a 3 on the name or attribute score as a sprint, not a backlog souvenir.

CTA

Make the brand a thing with stable Organization, Person, and Product attributes, then make those attributes boringly consistent everywhere.

Map this layer into the full stack via the AEO playbook, or get a baseline across entities, schema, and citations on /visibility — request a visibility audit.