Updated on 20 October 2026.
A missing answer does not establish that AI omitted your brand. First separate a complete answer, a refusal and a failed retrieval. Only usable text lets you check whether the brand is present. This guide produces an incident record and a next action, rather than another glossary of visibility metrics.
Classify the observation first
| Available evidence | Classification | Next action |
|---|---|---|
| Complete answer without the brand | Valid no-mention observation | Keep the text and observation conditions |
| Explicit refusal | Model refusal | Record separately; do not bypass safeguards |
| Blank view or missing record | Undetermined result | Check retrieval and completeness |
| Brand in the answer but missing from the dashboard | Possible classification error | Report the passage and name variant |
| Truncated answer | Incomplete observation | Apply a documented rule; do not invent the missing text |
A practical checking procedure
Keep the available text and message. A blank screen alone cannot tell you whether generation, retrieval or presentation failed.
Record the question, system and mode, country, language and timestamp with timezone. Include only information needed for diagnosis, without customer data or secrets.
Compare the stored response and displayed result where both are available. Check truncation and verified brand aliases.
Assign a category from the table. Preserve refusals as a distinct outcome. Check the provider's documentation before deciding how they enter a particular metric.
Retry only when justified and permitted, and keep the retry as a new attempt. Fix configuration problems first; do not run an unlimited retry loop.
Copy this incident record
| Field | What to record |
|---|---|
| Observation scope | Question, system, mode, country, language |
| Time and provenance | Timestamp with timezone; available record reference |
| Symptom and evidence | Message; missing element; safe excerpt |
| Classification | Valid answer, refusal, missing data, incomplete record or matching error |
| Follow-up | Owner, next action, review date |
| Retry | Separate attempt; preserve the original |
When the incident can be closed
Close the incident when its outcome has evidence and a documented treatment. If the cause remains unresolved, retain a missing-data status and disclose the limitation. Do not replace an unknown result with zero visibility.
For your own mention-rate calculation, show planned, usable and missing observations separately. Excluding failed attempts does not make a biased sample representative. Do not keep only favourable retries. There is no universal repetition count that makes every question reliable.
Using the procedure with Semly
In Semly, start with the response for the relevant question and system. If the available view lacks technical evidence, send the incident record to support rather than inventing a cause. This is a proposed quality-control procedure, not a specification of Semly's internal metric algorithm.
Sources and scope
Public documentation explains monitoring. The classification workflow and incident record are the procedure proposed here, not brand results.
