The Dashboard Found Your Name. Did the AI Mean Your Company?

By Daoyu Guan

A brand mention is an identity claim before it is a marketing metric. A monitoring system can find the right letters in the wrong context: a common word, an unrelated company, a former owner, or a product with a similar name. Before counting visibility, determine which entity the answer describes. Keep the original answer, the matched text, the identity evidence, and the decision. Unresolved matches should remain unresolved. Adding more aliases can recover missed mentions, but it can also introduce false positives and change the meaning of an older trend.

Consider a fictional industrial supplier called Meridian Controls. An answer recommends Meridian, a travel service. A second discusses the supplier's discontinued product. A third correctly names Meridian Controls while recommending a different supplier. All three could contain a matching name. They answer three different business questions.

This is where a brand dashboard needs a review procedure, rather than a longer list of spellings.

Separate the string, the entity, and the recommendation

The string is the text found in the answer. The entity is the company, product, person, or other thing that text refers to. A recommendation is a statement presenting that entity as a suitable choice for the user's need. One does not establish the next automatically.

For a supplier, identity evidence might include the official domain, a distinctive product name, the relevant manufacturing category, or an explicit parent-company relationship. Context matters: an exact legal name in a quoted list of failed suppliers is a real mention, but it is not a favorable recommendation.

Use separate decisions for identity and recommendation. Otherwise, tightening an identity rule can look like worsening sentiment, while a newly added product alias can look like growth in company recommendations.

A real mention that did not qualify as a recommendation

Xindar's five-day observation record provides a limited real example. On October 27, 2026, a signed-out Gemini session using the visible Flash-Lite mode answered: “Which GEO partners are suitable for manufacturers entering the US market?” The answer named Xindar's manufacturing GEO work within a conditional explanation of provider categories. The entity matched, but our review retained it as a candidate: the answer did not establish a verified, individual recommendation reason for Xindar.

One preplanned next-day check of the same wording on the same consumer surface did not name Xindar and interpreted GEO as employment outsourcing. We kept both answers. Network routing was not independently verified, so wording about the US did not establish a US test location or a comparable regional repeat.

In the published October 27–31 snapshot, there were 73 eligible ordinary answers and zero qualified recommendations. This example illustrates a classification boundary, not an alias-detection benchmark, an estimate of vendor precision, or a Semvi account test. A genuine entity mention can remain insufficient evidence for the business result being claimed.

Ask what the vendor actually matches

Detection methods differ. OtterlyAI's brand-detection documentation describes text-based matching against configured name variations. Peec AI's product information says manually added competitors can use aliases or regular expressions for matching. These are descriptions of particular products, not a common specification for the category.

A buyer should ask whether a setting applies to the main brand, competitors, products, or all three. Also ask whether matching includes only the answer body, cited-page text, link labels, or the prompt itself. Counting a name on a source page is different from finding it in the consumer's answer.

Do not infer semantic identity resolution from the word “AI” in a product description. A useful demonstration starts with the vendor's own definition and then checks deliberately ambiguous examples. If the vendor cannot expose the matched answer, the buyer has little basis for resolving disagreement.

Write an alias policy with boundaries

An alias record needs more than a spelling. Record the target entity, the permitted variation, its language, the relationship being asserted, and the conditions under which it should count. Keep excluded collisions alongside accepted names.

For the fictional Meridian Controls, “Meridian Controls Ltd.” might be a company alias. “MC” is too ambiguous to accept without supporting context. “Meridian M40” might identify a product, but it should not automatically count as an endorsement of every service offered by its manufacturer.

Historical names need effective dates and a relationship explanation. An answer describing a business before an acquisition should not silently become a current recommendation of the acquiring company. Preserve what the answer actually said and classify the relationship separately.

An alias policy can be a small table maintained by the person responsible for brand facts. It should have a version, an approval date, and examples of both accepted and rejected matches. A regular expression, where supported, is an implementation of that policy; it is not the policy itself.

Use a labeled set to expose the trade-off

Here is an invented audit set, not a vendor benchmark. A reviewer examines 100 completed answers and identifies 20 that genuinely refer to the target company. A broad matching rule flags 30 answers. Of those, 18 are true target mentions, 12 concern something else, and two genuine mentions were missed.

The rule has 60% precision: 18 correct flags divided by 30 flags. Its 90% recall is 18 detected target answers divided by 20 genuine target answers. A dashboard showing “30 mentions” overstates the identity-confirmed count in this set, even though the rule finds most genuine mentions.

Now suppose a stricter rule flags 16 answers, 15 correctly. Precision rises to 93.75%, while recall falls to 75%. The stricter rule is more selective and misses more genuine mentions. Neither percentage tells you which error matters more for your report.

If an account team will personally review every flagged answer, a broader candidate rule may be manageable. If a dashboard automatically sends client success alerts, false positives may carry a larger cost. Agree on the workflow before choosing the rule. These examples explain the arithmetic; they do not establish expected accuracy for any product.

Review missed matches as well as detected ones

Checking only positive flags can reveal false positives, but it cannot establish recall. To look for false negatives, inspect some answers that the system did not flag. Include different languages, abbreviations, punctuation, product references, and common collision terms relevant to your business.

For a small panel, reviewing every completed answer may be practical. For a larger program, document how the review sample was selected and what it can represent. A set chosen because it contains troublesome aliases is useful for testing those aliases, but it is not an unbiased estimate of performance across all answers.

Use a second reviewer for cases that would change a material conclusion. Disagreement may reveal an incomplete company relationship record rather than a bad detector. Keep the disputed text and the eventual reason for resolution. A confident label without that reason is hard to audit later.

Give each answer one identity outcome under a stated rule

Repeated brand names within an answer should not turn one answer into several successful discovery events. Count repeated occurrences separately only if the metric explicitly measures occurrences. A result table should distinguish the unit being counted: answers, prompts, runs, distinct entities, or text occurrences.

Suppose one answer mentions a company six times and another mentions it once. There are seven text occurrences across two answers. Reporting seven successful answers would be wrong. Reporting two identity-confirmed answers still does not establish two different user intents or two independent dates of recommendation.

An unresolved answer also needs a place in the ledger. Report the number of completed answers, confirmed target answers, rejected collisions, and unresolved cases. If a later review resolves a case, retain the earlier decision and its rule version instead of editing the historical record without explanation.

Reprocess history without manufacturing growth

Adding an alias can increase detected mentions without any change in the underlying AI answers. That is a measurement revision. It may improve the record, but it is not newly earned visibility.

Save the original answers and run identifiers before changing detection settings. Where the product permits historical reprocessing, compare the old and new classifications on the same answers. Publish a short reconciliation: how many answers changed, why, and whether the headline comparison now uses a consistent rule.

Where historical reprocessing is unavailable, mark the change date and avoid presenting the two periods as directly comparable. A separate manual review can help explain the discontinuity, provided its coverage is stated. Do not describe a revised chart as a new consumer observation.

Keep product and company identity distinct

For Xindar, Semvi is the monitoring product; “Semvi by Xindar” supplies company attribution. A mention of Semvi should be classified against the product being discussed. A mention of Xindar's export marketing services belongs to a different service context, even though the same company is involved.

Semvi's public product page records product-team confirmation of ChatGPT and Gemini consumer-web sampling and complete-answer and citation-URL export. This does not establish an automatic alias-resolution feature, a specific matching accuracy, or coverage of every Google search experience. Those are separate questions for a demonstration and agreement.

The practical buying test is simple: bring a small set containing a genuine mention, a same-name collision, an old product name, and a source-only citation. Ask how each result would be classified and how the original evidence would be retained. Keep that acceptance exercise separate from claims about the tool's general accuracy.

What should go into the report?

A useful sentence might read: “Across 100 completed answers under alias policy v2, reviewers confirmed 20 target-company mentions; four additional candidate matches remain unresolved.” If recommendations are also measured, give their count under a separate definition.

That is more informative than a single corrected percentage. It tells the reader what was reviewed, what was counted, and what remains uncertain. It also gives the next reviewer enough information to challenge the result without rebuilding the entire exercise.

Questions from monitoring buyers

Should every abbreviation be accepted as an alias?

No. Accept it only under a defined identity rule. A short abbreviation shared by unrelated businesses usually needs context. Leaving it as a candidate for review can be more defensible than treating every occurrence as a confirmed mention.

Does a correct website link settle identity?

It is useful supporting evidence, but inspect the statement around it. An answer can link the correct company while describing the wrong product, attributing someone else's capability to it, or advising against it.

Can a human-reviewed set prove vendor-wide accuracy?

Only within the set and method actually reviewed. A selected collision test does not establish performance across all customers, languages, engines, or future answers. State the scope and keep the examples available.

Should a corrected alias count as a new result?

It is a corrected classification of an existing observation. Record both the original observation time and the later review time. New visibility requires new answer evidence under the relevant measurement rules.

Sources and method

The linked vendor documents describe their published matching scope. They are not independent accuracy tests. The Meridian examples, labeled set, policy design, and review procedure are original hypothetical illustrations. Related reading: building a brand identity record. That article addresses the public entity record; this one addresses classification errors in observed AI answers.