AI Brand Entity Resolution: A Codebook for Ambiguous Names

An AI brand answer is only useful when you know which real-world entity its name denotes. Entity resolution is the evidence-led decision that connects an observed brand mention to the correct organization, domain, social profile, or knowledge record. It prevents an audit from merging unrelated businesses or splitting one brand into phantom competitors.

This is AEOeye's operational codebook, not an official standard. It uses identity signals described by Google's Organization structured-data guidance, the sameAs property, W3C WebSchemas guidance, and Wikidata's identifier documentation. Schema markup can clarify a publisher's intended relationships, but it does not guarantee that an AI system will recognize, retrieve, or recommend the entity.

Table of contents

• What exactly are you resolving?
• Which identity signals should you collect?
• How should a reviewer label a match?
• What is the reconciliation workflow?
• How can teams use a copyable table?
• How should uncertainty be reported?
• What can this codebook not establish?

What exactly are you resolving?

Resolve one observed name in one answer against one target entity in a declared study. The target should have a stable entity_id, a preferred brand name, a canonical domain, and a note describing the scope: company, product, nonprofit, publication, or another organization.

For preserving the raw answer and its evidence, pair this codebook with AEOeye's AI citation data schema.

Which identity signals should you collect?

Collect several independent signals, then record where each came from. A name alone is a discovery hint; a corroborated domain, legal entity, social profile, and knowledge identifier can support a stronger decision.

Google recommends Organization markup for details such as name, URL, logo, and identifiers, and identifies sameAs as a way to point to pages that unambiguously represent the organization. Read that as a publishing practice, not as proof that every linked page is authentic. The Schema.org definition of sameAs describes an unambiguous identity relationship; the W3C WebSchemas note provides related context for representing equivalence on the Web.

How should a reviewer label a match?

Apply exactly one resolution label per observation: match, no-match, or uncertain. The label describes the available evidence at review time, not the model's confidence or the entity's commercial quality.

Strong signals include a canonical site linking to the same social profile, a legal name that clearly owns the brand domain, or a knowledge record whose description and official links align. Weak signals include a shared logo, a generic name, search-result proximity, or an AI answer's unsupported assertion. Never upgrade weak signals because the brand is familiar.

What is the reconciliation workflow?

Use a fixed sequence so reviewers do not unconsciously change the threshold from case to case.

1. Freeze the observation. Save the exact name span, surrounding sentence, visible link, answer ID, prompt, date, locale, and engine surface.
2. Generate candidates. Search the declared target set and collect name variants, abbreviations, products, parents, and similarly named organizations.
3. Check the canonical domain. Open the candidate's primary site and record redirects, displayed organization name, contact or legal page, and links to official profiles. Preserve raw and resolved URLs separately.
4. Check legal identity. Record the legal entity and jurisdiction only when a reliable public record or the organization's own disclosure supports it. A parent company relationship is not automatically an entity match.
5. Check social IDs. Capture stable profile URLs or handles, platform, and whether the account links back to the canonical domain. Treat an account as unverified when that loop is absent.
6. Check knowledge identifiers. Compare the identifier's label, description, aliases, and external links. Wikidata's identifiers guide explains the role of identifiers; it does not make a candidate correct merely because a Q-ID exists.
7. Reconcile contradictions. Note collisions such as two companies using the same name, an expired domain, or a social profile pointing to a different jurisdiction.
8. Assign one label. Apply match, no-match, or uncertain, cite each supporting source, and write a short reason another reviewer can audit.

How can teams use a copyable table?

Copy this table into a spreadsheet or annotation form. One row represents one observed brand span in one answer; do not silently combine repeated observations.

Replace the illustrative domains and identifiers with captured evidence. A blank field means “not observed,” not “false.” Include a source_captured_at timestamp when records can change, and retain an audit trail when a later reviewer changes the label.

How should uncertainty be reported?

Uncertainty should be explicit, local, and reversible. Write what is unknown, which signal conflicts, what check was attempted, and what evidence would change the label. Avoid a single unexplained confidence percentage that hides the reason for doubt.

Useful notes include: “canonical site names a subsidiary, while target is parent”; “social handle is similar but does not link back”; or “AI answer gives no URL, so candidate selection relies on context only.” Preserve rejected candidates when name collisions could recur.

The NIST AI Risk Management Framework emphasizes documenting context, risks, and limitations. This codebook applies that governance instinct to entity decisions; it does not claim NIST defines these labels or endorses AEOeye's implementation. For broader measurement context, compare the AEOeye visibility score methodology and AI search audit methodology template.

What can this codebook not establish?

It cannot prove that an AI provider used your structured data, that a sameAs link was crawled, that a knowledge graph entry is complete, or that a resolved entity will be recommended. It cannot establish legal ownership from a social username.

Schema markup is a communication layer, not a recognition guarantee. Keep the raw answer, the decision rule, the evidence URLs, and the unresolved alternatives. When you change the target definition or evidence threshold, version the codebook and report the change instead of rewriting history.

Use this codebook before calculating brand presence or recommendation rate. Then run a free AEOeye audit and retain its raw answers alongside your reconciled entity table.