AI Brand Entity Audit: Names, Products, Aliases and Facts

Before asking ChatGPT, Gemini or Perplexity to understand your brand better, your team must answer a more basic question: what exactly is each thing you publish under that name?

A company may have a legal name, a commercial brand, named products, grouped services, spokespeople, locations and legacy names. When marketing, sales, support and partners describe those pieces differently, AI systems receive incompatible signals.

An entity audit does not fix a false answer you have already found. That problem has its own step-by-step guide to fixing wrong AI information. This audit happens earlier: it creates the documentary reference that content, public relations, product and structured data should share.

What an entity audit decides

The audit must produce decisions, not a folder of screenshots. At the end, the team should know:

1. Which things deserve their own entity identity.
2. Which name is canonical for each entity.
3. Which aliases are valid, contextual, historical or forbidden.
4. How company, brands, products, services, people and locations relate.
5. Which facts may be stated and with what evidence.
6. Which collisions can cause mistaken identification.
7. Who approves changes and when each record must be reviewed.
8. Whether the identity is ready, conditionally ready or not ready for optimization.

The output is an identity register, not a keyword list. A keyword expresses how an audience searches; an entity expresses who or what the statement is about.

When to run it

Run the audit before:

• Redesigning a website or migrating domains.
• Launching a brand, product or category.
• Expanding into another country or language.
• Implementing structured data.
• Building a prompt bank or configuring a measurement tool.
• Integrating an acquired company.
• Changing a name, positioning or product architecture.
• Correcting repeated inconsistencies across AI answers.

It is also necessary when two products have similar names, when a commercial brand does not match the legal entity or when the company has a namesake with stronger digital authority.

Step 1: Define scope, criteria and owners

Do not begin by collecting every name found online. First define the system you need to explain.

Write one scope question:

Which entities must a person distinguish to understand who we are, what we offer and where we operate?

Then assign three roles:

Product, legal, marketing and operations may contribute, but an entity cannot have four "official" versions. If no one has authority to decide, the first audit issue is governance.

Step 2: Build the canonical inventory

Create one row per real entity, not one per textual variant.

Use stable IDs because names can change. The ID preserves history, connects facts and prevents a reorganization from creating two entities where only one exists.

Include only elements with an identification impact:

• Organization and business units.
• Commercial brands.
• Products and suites.
• Services with a distinct proposition.
• People whose identity represents the company.
• Locations with a commercial or legal role.
• Retired brands or products still present in sources.

Step 3: Separate legal, commercial and product names

One common source of ambiguity is treating all names as equivalent.

Record one disambiguation sentence per entity:

Mentio is a [type of entity] that [main function], not [entity it may be confused with].

The sentence does not need to be published verbatim. It is a test: if the team cannot complete it without disagreement, the identity is not resolved.

Step 4: Create an alias policy

An alias is not simply "another way to spell the name." It needs a usage decision.

Classify every variant:

• Approved: may be used publicly as an equivalent.
• Contextual: valid only in a market, channel or language.
• Historical: helps recognize older references but must not be presented as current.
• Common error: recorded for detection, not publication.
• Forbidden: may confuse another entity or break a legal rule.

Include abbreviations, domains, social handles, translations, acronyms and unaccented variants. If an alias matches a common word or a competitor, mark it as a collision.

Step 5: Model hierarchy and relationships

Names in isolation do not explain whether an offer belongs to a company, whether one product replaced another or whether two brands share an owner.

Use explicit relationships:

• is a brand of
• is a product of
• is part of
• replaces
• was formerly called
• operates in
• is owned by
• is a spokesperson for

Every relationship should include a start date, an end date when relevant and evidence.

Step 6: Build the fact register

A correct name cannot compensate for contradictory facts. Create one row per claim you intend to support.

Prioritize facts that affect recommendation or trust:

• What the entity offers.
• For whom and in which market.
• Ownership and relationship with other brands.
• Geographic availability.
• Pricing or terms, when public.
• Integrations and capabilities.
• Certifications, awards and figures.
• Foundation, acquisition or renaming dates.

Do not record "leader," "best" or "most advanced" as a fact without verifiable criteria. Those expressions may be commercial positioning, but they should not contaminate the factual register.

Step 7: Assign evidence levels and expiry

Not every source serves the same purpose.

A material fact needs at least one valid E1 source. When it depends on external recognition, add E2 or E3. E4 helps identify risk; it does not approve a statement.

Set expiry by volatility:

• Legal identity: annual review or after a corporate change.
• Price, plan or availability: monthly or quarterly.
• Integration and capability: quarterly.
• Certification: before expiry.
• Customer or market figure: with every publication.

Step 8: Find contradictions and collisions

Compare the register with every surface that already describes the brand:

• Website and subdomains.
• Social profiles and directories.
• Marketplaces and partner pages.
• Documentation, help content and PDFs.
• Press releases and interviews.
• Legal and commercial listings.
• Search results and AI answers.

Record every conflict:

Not every difference requires absolute uniformity. A description may adapt to its channel without changing the subject, category or fact. Fix first what could make a person attribute the offer, ownership or capability to the wrong entity.

Step 9: Run disambiguation tests

Prepare cases that force entity distinction, not only favorable questions.

1. Exact name without context.
2. Common alias without parent brand.
3. Product queried without naming the company.
4. Historical name after an acquisition.
5. Brand and namesake in the same query.
6. Capability that belongs to only one product.
7. Market where the name changes.
8. Public person with several affiliations.
9. Retired fact still present in a source.
10. Frequent misspelling.

For each case, define the expected entity, relationship, permitted fact and evidence. These rules also improve an AI visibility tool trial, because they reduce false positives from aliases and products.

Step 10: Score readiness

Use a simple scale for each priority entity:

Define three outcomes:

• Ready: no critical dimension is at 0 and all high-risk collisions are resolved.
• Conditionally ready: work may proceed, but dated tasks remain that do not alter the main identity.
• Not ready: there is no agreement on the name, relationship, ownership or essential facts.

Do not average away a critical collision. A brand is not ready because five dimensions are perfect if its main product is confused with another company.

Minimum register template

Register version:
Date:
Custodian:

Entity ID:
Type:
Canonical name:
Legal name:
Descriptor:
Parent entity:
Relationships:
Markets and languages:
Approved aliases:
Contextual aliases:
Historical names:
Common errors:
Forbidden aliases:
Disambiguation sentence:

Approved facts:
Evidence per fact:
Review date:
Expiry:
Collisions:
Decision: ready / conditionally ready / not ready
Actions, owner and date:

Version the file. Do not overwrite ownership relationships, retired names or facts that have already been published without preserving history.

Example: A SaaS company with two products

A company operates under the "Northstar" brand and sells "Pulse" and "Atlas." During the audit it finds:

• The legal entity appears as if it were a second brand.
• "Pulse" matches several unrelated applications.
• Two pages describe "Atlas" as a product and another as a service.
• A directory uses the company's former name.
• A retired integration remains in a PDF.

The team creates ORG-001 for the organization, BRAND-001 for Northstar and two product entities. It defines that the legal name is used only in legal contexts, adds "Pulse by Northstar" as a contextual form, removes the integration from the fact register and marks the former name as historical with an effective date.

The identity is conditionally ready: the directory and PDF still need updates, but the map now lets every team publish the same company-brand-product relationship.

How the map moves into execution

The register should not remain isolated. Give a controlled view to:

• Content: approved names, descriptors, relationships and facts.
• SEO/GEO: owning pages, disambiguation and contextual terms.
• Development: the entities and relationships that schema markup should represent, without turning the map into code.
• PR and partnerships: names and facts that third parties can verify.
• Product and support: current capabilities and retired language.
• Measurement: aliases, products and collisions that must be distinguished.

When the goal is to improve presence in a specific engine, the map also becomes an input to a Gemini brand visibility strategy. Identity is decided first; then teams choose the surfaces and signals that express it.

Mistakes that invalidate the audit

1. Copying names from the website without deciding which is canonical.
2. Treating every keyword as an entity.
3. Combining company, brand and product in one row.
4. Approving aliases without context or restrictions.
5. Recording facts without a source, owner or expiry.
6. Confusing a commercial claim with a verifiable fact.
7. Ignoring historical names and acquisitions.
8. Fixing style differences before critical collisions.
9. Implementing schema before validating the hierarchy.
10. Closing the audit without a readiness decision.

When you prepare a launch, reuse this entity map as the foundation for monitoring a product launch in AI and limit evaluation to the facts that change on that date.

FAQ

What is an AI brand entity audit?

It is a documentary review that defines which entities make up the brand, what they are called, how they relate and which facts may be stated about each one. Its output is a verifiable map that reduces ambiguity before publishing content, structured data or AI visibility campaigns.

How is it different from fixing false information in ChatGPT?

Correction starts with an error that has already been observed and aims to update its sources. An entity audit happens earlier: it finds conflicting names, undefined relationships and unsupported facts before different sources describe the brand incompatibly.

Which entities should the map include?

At minimum, review the organization, commercial brands, products, services, relevant public people, locations and historical entities still present in sources. Include only those that can affect how a person or system identifies the offer.

How should aliases and former names be managed?

Link every alias to a canonical entity, classify it as approved, contextual, historical or forbidden, and define usage rules. Former names need effective dates and a clear indication of whether they remain useful for discovery or only for historical reference.

What evidence does a brand fact need?

Each fact needs exact wording, an owned source, an external source when material, an owner, a review date and an expiry. Sensitive or changeable facts such as pricing, coverage, ownership or certifications require stricter controls.

When is the brand ready for AI visibility optimization?

It is ready when priority entities have a canonical name, hierarchy, aliases, facts and consistent evidence, with no unresolved critical collisions. The decision can be ready, conditionally ready or not ready, always with owners and dates for closing conditions.

Turn scattered identity into a shared reference

Optimization starts too late when every team publishes a different version of the brand. A small, verifiable and governed register gives people, platforms and systems a common foundation.

Check how your brand appears in AI answers with Mentio ->

Want to know if AI mentions your brand?

Discover your visibility in ChatGPT, Claude and Gemini in minutes.

Related articles