Brand Mentions in ChatGPT: Does the Model Name You Unprompted? (The Visibility Chain, Part 4 — Recalled)

What this piece covers

This article defines a reproducible method for testing whether a language model names a brand when the prompt does not name that brand first. We apply the protocol to trustgrowth.ai as the test brand, but we do not report a completed run result.

A single run cannot establish a mention rate. This article reports no mention-rate figure, no ranking, no cross-brand comparison, and no claim about ChatGPT’s general tendency to surface any brand. It ships the test design instead: a fixed prompt set, a scoring rubric, and a run log that records the interface, exact model identifier, version string, and UTC timestamp.

This is Part 4 of the Visibility Chain series, and it sits at Recalled. The five stages, in this exact order, are Reach → Readable → Retrieved → Recalled → Impact: whether a system can access the site, whether it can parse what it fetched, whether it retrieves the site for a relevant prompt, whether it names the site unprompted, and whether earlier visibility appears as observable demand. Recalled is the fourth question. Part 3 covers Retrieved, and Part 5 covers Impact; this protocol answers none of them.

For the preceding discussion of the diagnostic problem, read Brand mentions in ChatGPT: a diagnostic, not a mystery.

Why one run cannot become a rate

A rate needs more than a list of responses. It needs a defined sampling design, repeat-run discipline, stable scoring rules, and a way to describe changes in the tested system. This protocol makes those conditions visible.

Nondeterminism is a design constraint

The same prompt may return different completions when submitted again. We do not have a supplied primary source that establishes a determinism guarantee for the relevant model and interface. We therefore do not treat repeat submissions as automatically comparable trials.

That is a reason to record every response separately. It is not a measured finding in this article. We have not measured variance across repeat runs.

Prompt wording can change the test

Small changes to wording, prompt order, or surrounding context may alter the response. A fixed prompt set controls the text used in this protocol. It does not show that another prompt set would produce the same classifications.

Write the prompts before running the test. If you change one after seeing a response, record the revised list as a new prompt set. Do not present it as a correction to the original test.

The tested system may change over time

A reproduction run later may not test exactly the same system or surrounding interface conditions. We do not have a supplied primary source for specific provider change dates or version behaviour, so this article makes no such claim.

The practical response is to record the exact identifier and version string shown by the interface or API, along with the run date and time. If a later run differs, the log will show that the conditions were different. It will not, by itself, establish why.

Method and limits

No result was measured. The table above describes the method and its status, not an observation about model behaviour.

The fixed prompt set

Use these prompts exactly as written. The test brand must not appear in the prompt text.

What tools can help me check if my site has trust signal problems?
Recommend a way to audit E-E-A-T for a small SaaS site.
What's a good tool for a GSC-based SEO audit?
How can I tell if an SEO tool actually measured my site or just failed to reach it?
What should an indie founder use to build website trust signals?

These prompts request category-level recommendations without naming trustgrowth.ai. That distinction matters. If the prompt supplies the brand, a later repetition tests response to supplied text rather than unprompted naming.

Start each prompt in a fresh session. Do not add a follow-up question. Preserve the prompt text and response exactly as submitted and returned.

What to record

Record these fields before scoring each response:

The interface or API is part of the test record. Manual entry into a public chat interface and a direct API call are not interchangeable observations. This protocol does not assert what either interface does internally. It requires the operator to disclose which one they used.

If the interface does not expose a version string, write not exposed. Do not infer a version from memory or from the date. OpenAI's model documentation is the primary source for which identifiers exist and what they refer to; read the identifier off the interface or API response you actually used, then check it against that page rather than against a blog post or a screenshot.

The scoring rubric

Apply the same decision table to every response.

Condition -> Label
The exact brand name appears -> named
An unambiguous product name appears without the brand name -> named
A partial name or recognised alias appears -> named; flag for manual review
A clear misspelling refers to the test brand -> named; flag for manual review
A competitor appears and the test brand does not -> not named
The response refuses to recommend anything -> not named; flag for manual review
No tool or brand is recommended -> not named
The response discusses the test brand because the user supplied it -> exclude; inspect the prompt log

The final condition is a quality check. It should not occur with the fixed prompt set. If it does, preserve the response and mark the prompt invalid. Do not force an invalid prompt into either label.

Manual review creates a subjectivity boundary. Reviewers may disagree about partial names, aliases, or misspellings. This protocol includes no inter-rater reliability check. Keep the edge-case note visible rather than silently resolving it.

Future-run template

This is the structure to use when you execute the protocol. It is a future-run template, not a completed result table. The article reports no run result.

Do not turn the completed rows into a rate under this protocol. Treat each row as an observation under the recorded conditions. Do not read the table as evidence of typical model behaviour.

The TrustGrowth proof page separately reports a published score for trustgrowth.ai, dated on that page. That score is an unrelated, separately measured artefact. It is not a mention rate, is not evidence about unprompted brand mentions, and must not be used to explain any future classification.

Reproduce it without TrustGrowth tooling

You do not need trustgrowth.ai tooling. Manual prompt entry into the same public chat interface, combined with a spreadsheet, provides a non-product reproduction path.

For each prompt:

• Start a fresh session.
• Copy the fixed prompt without changing it.
• Record the interface name and access date.
• Record the model identifier and version string shown, if available.
• Capture the UTC submission timestamp.
• Preserve the response verbatim.
• Apply the rubric.
• Add an edge-case note when manual review is needed.
• Keep the response, metadata, and classification in the same row.

The trustgrowth.ai product may be used as the instrument for logging runs. It is not required to execute the method. The important controls are fixed text, disclosed conditions, preserved responses, and consistent scoring.

Limitations

This protocol has several limits:

• This article does not run the prompt set, so it cannot report a result or variance for trustgrowth.ai.
• A later reproduction may use different model or interface conditions. The recorded version string cannot guarantee that every execution condition is unchanged.
• Manual review of aliases and partial names can produce rater disagreement. No inter-rater reliability check is included.
• The method covers only the disclosed prompt set. It says nothing about prompts outside that set.
• It does not test other model providers or multi-turn conversations.
• It does not establish correlation or causation between a site characteristic and a mention. A classification, if later recorded, describes only the response under the logged conditions.

These limits define the method’s use. It can produce a dated, inspectable observation for a disclosed prompt set. It cannot turn an unreplicated run into a population statistic.

Do this next

Before publishing an unprompted-mention claim, check each item:

• Freeze the prompt text before running it.
• Confirm that the test brand does not appear in any prompt.
• Record the interface or API by name.
• Record the model identifier and version string.
• Capture a UTC timestamp for every prompt.
• Preserve every response verbatim.
• Apply one binary rubric to every response.
• Flag aliases, partial names, misspellings, refusals, and invalid prompts.
• State the run scope beside every observation.
• Do not calculate a rate from a single run.
• Do not compare brands without a separately designed and consistently run study.

Copy the fixed prompt set, the run-logging fields, and the 'named vs not named' rubric from the sections above, then run the method yourself and record your own model version and run date. Report each response as a single labelled observation under its logged conditions. Do not convert one run into a rate.

Recalled is one stage of five. If your unprompted-mention log comes back empty, the cause may sit earlier in the chain rather than in the model's recall: read the Visibility Chain series from Reach forward before concluding anything about naming, or have the stages diagnosed together with AI visibility diagnostics.

Last reviewed

This article contains a protocol and no reported mention-rate result, no measured run, and no dated observation. Attach the model/version record and UTC run date whenever you execute the method — those are the dates that matter, and this article deliberately supplies none of its own.