# AI brand monitoring: a cadence that catches real change

AI brand monitoring done as change detection: cadence, sample sizes, alert thresholds, a wave log and an escalation ladder for what AI says about you.

---


AI brand monitoring is the routine of asking the same fixed questions of AI assistants at a set interval, recording what they say, and comparing each round with the last one so that a real change stands out from ordinary variation. It is change detection. The deliverable is not a dashboard of scores but a short list of things that moved, with a decision attached to each.

The difficulty is that an assistant can give two different answers to the same question within a minute. A monitoring routine that reacts to every difference will exhaust you and teach you nothing. One that never reacts will miss the day an assistant starts repeating a false claim to every prospective client. The work sits between the two: a cadence matched to your exposure, samples large enough to mean something, and thresholds written down before you look at the data.

This guide covers the ongoing routine only: how often to check, how big each round should be, what counts as an alert, how to log and compare rounds, and who does what when something moves. It does not repeat how to build the first baseline audit, how to file a correction, or how assistants source their facts. Where it touches a provider feature it follows the provider's own page, named in the text. The sample-size figures are computed for this guide from the arithmetic shown, and the cadence defaults come from our experience on files, written as tendencies and not as rules of the machines.

<div class="box"><b>The short version</b>
<ul><li>Monitor claims, not prompts. Keep a register of 8 to 15 claims that matter, each with an owner and a severity, and attach two or three fixed questions to each.</li><li>Match cadence to exposure: weekly in the weeks around a launch, a raise or a dispute, monthly in a normal period, quarterly when little is at stake, plus an extra round after any event.</li><li>Ten runs per question per round is the practical floor for comparing rounds. Below that, only a large swing means anything.</li><li>Write thresholds before looking: one damaging false claim triggers a same-day confirmation, a shift of about 50 points in how often a claim appears triggers a ticket, a new cited source triggers a review.</li><li>Run a control question each round. If it shifts too, the platform changed, not your reputation.</li></ul></div>

## What AI brand monitoring watches, and how it differs from an audit

AI brand monitoring watches a fixed list of claims over time and reports differences. An audit is a one-off measurement that builds the first picture; monitoring is what you do after it, on a schedule, with the audit as the reference point.

An audit wants breadth. Monitoring wants stability and sensitivity: the same questions, worded identically, run under the same conditions, so that any difference comes from the world and not from your phrasing. Reword a question and you have started a new audit.

Monitoring fails by decay: a round is skipped, then only one assistant is checked. A good routine is small, written down and assigned to a named person.

Every row you keep should answer "what would I do if this moved?" If nothing, remove the row.

## Set the cadence by exposure, not by habit

The right interval depends on how much a wrong or changed answer would cost you in the next few weeks, not on a calendar convention. Four situations cover most cases.

<div class="tablewrap"><table><thead><tr><th>Situation</th><th>Cadence</th><th>Size of each round</th><th>Why</th></tr></thead><tbody>
<tr><td><strong>Active exposure</strong>: raise, launch, hire, litigation, press cycle</td><td>Weekly, for the length of the event plus two weeks</td><td>Critical claims only, 10 runs each, two assistants</td><td>Counterparties are looking now; a wrong answer is costly within days</td></tr>
<tr><td><strong>Open correction</strong>: you changed a source or filed a report</td><td>Every 10 to 14 days until the claim holds clear for two rounds</td><td>The affected claim plus the control question</td><td>You need to see whether the fix landed and whether it stays</td></tr>
<tr><td><strong>Normal period</strong></td><td>Monthly</td><td>Full register, 10 runs per question, two or more assistants</td><td>Enough to catch drift before it becomes the default story</td></tr>
<tr><td><strong>Low exposure</strong>: private individual, no public role, nothing pending</td><td>Quarterly</td><td>Full register, 10 runs</td><td>A low-cost check that nothing new has attached itself to your name</td></tr>
</tbody></table></div>

Add an event round after anything that could change the evidence: a news article, a change of role, a rebrand, a site migration, or the removal of a page an assistant used to cite. Do not go weekly out of anxiety: weekly rounds on a quiet profile mostly produce noise, so add runs per round instead.

Providers update models and search features on their own schedules. OpenAI publishes a [ChatGPT release notes page](https://help.openai.com/en/articles/6825453-chatgpt-release-notes) with dated entries, newest first, covering features, plans and model retirements; check it when a round looks odd. Google says AI Overviews appear only when its systems judge them to add value beyond classic results, so they often do not show at all. Record the date and setting of every round, so a platform change can be spotted later.

## Build a claims register, not a prompt library

A claims register lists the statements about you that you care about, ranked by what a wrong version would cost. Prompts are then chosen to test those claims. Build the register once, review it every quarter, and keep it short: 8 to 15 rows is workable for one person or one brand, and more than 25 will not be run faithfully.

Each row carries six fields: the claim in plain words, its severity, its desired state, the fixed questions that test it, the page that should support it, and a named owner. Severity has three levels. Critical means a false version would damage a decision, such as a wrong allegation, a wrong license or credential status, a mix-up with another person, or a false safety or legal statement. Important means a wrong version would mislead but not injure, such as a wrong job title, old address or outdated product line. Background means a missing or thin statement that you would like to see but that does not hurt.

The desired state matters most. For a critical claim it is usually "absent". For an important claim it is "correct in most runs". For a background claim it is "present". Writing it down in advance tells you later whether a movement is good news.

Attach two or three questions to each claim. One should be direct, in the way a stranger would ask. One should be indirect, where the claim could appear as part of a wider answer, such as "should I hire this person" or "is this company reliable". A claim that shows up only in indirect questions is the kind that spreads quietly into recommendations.

Add two special rows. A control row asks about a stable, neutral subject unrelated to you, such as a long-established public institution with an unchanging founding date, and exists to detect platform changes. A sentinel row asks a known, slightly obscure fact about you, such as the year you founded your company. If a sentinel starts returning "I could not find information", you have lost a signal, which is a finding even though nothing false was said.

## Size each round so that a change means something

A round must be big enough that a difference between rounds is unlikely to be chance. Each observed share is only an estimate. The 95 percent intervals below use the Wilson method and are computed for this guide.

<div class="tablewrap"><table><thead><tr><th>Runs per question</th><th>Claim seen 0 times</th><th>Claim seen in about half</th><th>Claim seen every time</th></tr></thead><tbody>
<tr><td><strong>5</strong></td><td>true rate 0 to 43 percent</td><td>2 of 5: 12 to 77 percent</td><td>57 to 100 percent</td></tr>
<tr><td><strong>10</strong></td><td>0 to 28 percent</td><td>5 of 10: 24 to 76 percent</td><td>72 to 100 percent</td></tr>
<tr><td><strong>20</strong></td><td>0 to 16 percent</td><td>10 of 20: 30 to 70 percent</td><td>84 to 100 percent</td></tr>
</tbody></table></div>

Read the first row plainly: after five zero-hit runs you cannot rule out a claim that appears in four of every ten answers. After ten zero-hit runs the ceiling falls to under three in ten. That is why "I checked and it was fine" after one or two runs is weak evidence.

A second figure matters for rare but damaging claims. If a false claim appears in 10 percent of answers, the chance that n runs show it at least once is 1 minus 0.9 to the power n.

<figure class="fig">
<figcaption><b>Chance of seeing a claim that appears in 10 percent of answers</b><span>Share of rounds that show it at least once, by runs per round; computed as 1 minus 0.9 to the power n</span></figcaption>
<div class="fig-bars">
<div><span>3 runs</span><i style="width:42%"></i><b>27%</b></div>
<div><span>5 runs</span><i style="width:63%"></i><b>41%</b></div>
<div><span>10 runs</span><i style="width:100%"></i><b>65%</b></div>
</div>
<p class="fig-src">Computed for this guide; assumes each run is independent and the claim has a constant 10 percent rate. Real runs on one assistant are not perfectly independent, so treat these as optimistic.</p>
</figure>

Even ten runs miss a 10 percent claim about a third of the time. Our default is ten runs per question per assistant in a normal round and five when only confirming.

## Write alert thresholds before you look at the data

An alert threshold is a rule, fixed in advance, that turns an observation into a task. Without one, every wobble is open to interpretation and the loudest worry wins. The thresholds below are working defaults, not laws, and they are built on the arithmetic above.

<div class="tablewrap"><table><thead><tr><th>Level</th><th>Trigger</th><th>First action</th><th>Triage within</th></tr></thead><tbody>
<tr><td><strong>1: Critical claim</strong></td><td>A critical false claim appears in any run</td><td>Run five more of the same question on the same assistant; open a case if it appears again</td><td>Same working day</td></tr>
<tr><td><strong>2: Rate shift</strong></td><td>An important claim moves by about 50 points or more between two rounds of ten runs, and holds in the next round</td><td>Trace the cited sources; check for a platform change using the control row</td><td>Within a week</td></tr>
<tr><td><strong>3: New source</strong></td><td>A page appears among citations that was not there in the last three rounds</td><td>Read it; record whether it is accurate, owned and likely to persist</td><td>Within a week</td></tr>
<tr><td><strong>4: Lost signal</strong></td><td>A sentinel or background claim drops out for two rounds</td><td>Check the supporting page is still live, indexed and consistent</td><td>Within two weeks</td></tr>
<tr><td><strong>5: Noise</strong></td><td>Anything else, including a single odd answer on a claim that is not critical</td><td>Log it and take no action</td><td>Next round</td></tr>
</tbody></table></div>

The 50-point figure comes from a Fisher exact test, which asks how likely a split this lopsided is if both rounds had the same true rate. With ten runs in each of two rounds, a move from 1 of 10 to 6 of 10 gives a two-sided p-value of about 0.06, and 1 of 10 to 7 of 10 gives about 0.02. A move of 40 points, from 1 of 10 to 5 of 10, gives about 0.14, and 3 of 10 to 7 of 10 gives about 0.18. Neither is distinguishable from chance. This is a rule of thumb: assistants are not random number generators, and runs within a round are correlated.

<aside class="callout">
<span class="callout-label">Rule</span>
<h4>One round never proves a trend</h4>
<p>Except for a critical false claim, require the movement to show in two consecutive rounds before you act on it. A single odd round is a reason to schedule an extra check, not a reason to change your pages.</p>
</aside>

Level 1 is the exception to the two-round rule, because waiting costs more. If five reruns do not repeat the claim, record a one-off and rerun it next round. If it repeats, you have moved from monitoring to correction, and the saved evidence is the first page of the case.

## Log each round and compare it with the last

The log is what makes monitoring a control and not a feeling. It must let a person who was not there read last March's round and see what was asked, of what, when, under which settings, and what came back.

Keep one row per run, with these fields: round identifier, date, assistant and version label as shown, mode or setting such as search on or off, logged-in or not, location if the product shows one, the exact question, the full answer text, each cited source, and the claims detected. Then keep one summary row per claim per round: runs, hits, hit rate, sources cited, and the change since the previous round.

The comparison has four outputs: new claims, vanished claims, rate shifts and source changes. Report them in a one-page note after each round, with the action, owner and date for every item at level 3 or above.

<figure class="fig">
<figcaption><b>Run one monitoring round</b></figcaption>
<ol class="fig-steps">
<li><b>Freeze the conditions</b>Open a fresh session in a separate browser profile, note whether search is on, and record the assistant label and date before the first question.</li>
<li><b>Run the control row first</b>Ask the control question and compare it with the last round. If its answer shifted in substance, flag the round as platform-affected.</li>
<li><b>Run each register question ten times</b>Use exactly the same wording each time, in a new conversation for each run, and paste the full answer and citations into the log.</li>
<li><b>Tag the claims</b>Mark each claim as present or absent, then fill in the summary row with hits, rate and sources.</li>
<li><b>Apply the thresholds</b>Compare with the previous round, mark every item at level 1 to 4, and put the rest in the noise column.</li>
<li><b>Write the note and assign owners</b>One page, dated, with the actions. File it with the log so the next round starts from it.</li>
</ol>
</figure>

## Separate a real change from a platform change

The most expensive mistake is acting on a change in the assistant as though it were a change in the evidence about you. Four causes produce movement: a change in the sources, a change in the world (news, a role change), a change in the platform (a model update, a new default mode, different citation display), and a change in your own method (account, region, search on or off, reworded question). Only the first two are about you.

The control row is how you separate the third cause from the others. It asks about a stable subject that has not changed. If the answer to the control question shifts in tone, length, structure or sourcing in the same round that your claims moved, treat the whole round as platform-affected. Re-run the register a few days later before drawing any conclusions. A control question is not proof; it is an alarm that says "check the platform before you check yourself."

Google's [AI features page](https://developers.google.com/search/docs/appearance/ai-features) says AI Overviews and AI Mode can run several related searches to build a response, and that the two features may use different models and techniques, so their links can differ. Treat them as separate surfaces in the register. It also says AI Overviews appear only when its systems judge them to add value, so an absent overview is not a sign that anything changed about you. Record "no overview shown" as its own result, not as a miss.

Control the fourth cause with a one-page protocol: account type, browser profile, region, mode and exact wording. Anything outside it is a new baseline.

## An escalation ladder: who does what when something moves

Monitoring without a ladder ends in a spreadsheet nobody opens. The ladder says who looks at each level, what they are allowed to do, and when it stops being a monitoring matter.

The person who runs the round triages and writes the note. They do not change public pages alone. The claim owner decides on content, and anything touching a legal claim goes to counsel first.

A wrong claim traced to a page you own is fixed by editing that page and requesting a recrawl. One traced to a third-party page goes to the publisher or platform, with the evidence. One with no traceable source goes to the provider's reporting route while you keep monitoring it. A claim that is accurate but unwelcome is not an escalation: it is a content question about adding accurate context, and the ladder has no step for hiding lawful reporting.

The same Google page says sites shown in AI Overviews and AI Mode count toward overall Search traffic and appear in the Performance report under the Web search type. That is data about visits, not about what the answer said, so it complements the log. Google's Search Central blog also carries a post titled ["Introducing Search Generative AI performance reports in Search Console"](https://developers.google.com/search/blog/2026/06/gen-ai-performance-reports); its body could not be read for this guide, so check what it covers.

## A worked scenario: a small consultancy over twelve months

This is an invented scenario with generic parties and assumed figures, meant to show the rhythm.

A founder runs a small consultancy. A baseline audit found one important error: assistants describe the firm as based in a city it left, in 6 of 10 runs. It also found that the firm's own site is cited in only 2 of 10 runs for its services. The register has ten claims; one is critical (a mix-up with a similarly named firm that has had a regulatory problem), and the desired state is "absent".

<div class="tablewrap"><table><thead><tr><th>Month</th><th>What happens</th><th>Cadence and result</th></tr></thead><tbody>
<tr><td><strong>Month 1</strong></td><td>Baseline round. The founder corrects the location on the site and two directory profiles</td><td>Round on day 1; correction round at day 12: wrong location in 4 of 10</td></tr>
<tr><td><strong>Month 2</strong></td><td>Correction round again at day 26</td><td>Wrong location in 1 of 10; a Fisher p-value of about 0.06 against the baseline, so it holds; a second clear round needed</td></tr>
<tr><td><strong>Month 3</strong></td><td>Monthly round. The mix-up claim appears once in one run</td><td>Level 1: five reruns, one repeat; case opened, evidence saved, source traced to an outdated directory entry</td></tr>
<tr><td><strong>Months 4 to 5</strong></td><td>The directory is corrected; the firm announces a new service</td><td>Weekly rounds on the critical row and the new claim; the mix-up is absent for three rounds</td></tr>
<tr><td><strong>Month 6</strong></td><td>Control row shifts after a platform update; claims also move</td><td>Round flagged as platform-affected; rerun after four days; most movement reverses</td></tr>
<tr><td><strong>Months 7 to 12</strong></td><td>Normal period</td><td>Monthly rounds; quarterly register review; one level 3 alert for a new review-site citation</td></tr>
</tbody></table></div>

The first correction took two rounds to confirm; a single good round would have misled. The control row stopped the founder rewriting pages in response to a change that was not theirs. The figures are assumptions; providers do not publish how fast a changed page reaches an answer, and in our experience corrections to owned pages usually show over weeks, with wide variation.

## Tools or a spreadsheet: what to ask before you buy anything

A spreadsheet and a protocol are enough for 8 to 15 claims. We name no paid tool because we have not read a vendor's own documentation for this guide. Judge any tool against questions you can verify.

<div class="tablewrap"><table><thead><tr><th>Question to ask</th><th>Why it matters</th><th>Red flag</th></tr></thead><tbody>
<tr><td><strong>Does it store full answer text and citations?</strong></td><td>You need to retag, audit and use the evidence in a report</td><td>Only a score or a sentiment label is kept</td></tr>
<tr><td><strong>Can you fix the wording and settings?</strong></td><td>Comparison requires identical conditions</td><td>Prompts are rewritten or sampled for you</td></tr>
<tr><td><strong>How many runs per question?</strong></td><td>One run per prompt cannot separate noise from change</td><td>A single answer reported as "your visibility"</td></tr>
<tr><td><strong>Does it say which product surface it queries?</strong></td><td>An API answer and a consumer app answer can differ</td><td>No statement of the surface, version or mode</td></tr>
<tr><td><strong>Can you export everything?</strong></td><td>Your log must outlive the contract</td><td>Data only viewable inside the tool</td></tr>
</tbody></table></div>

Providers set their own terms on automated access. OpenAI's [terms of use](https://openai.com/policies/row-terms-of-use/) list, among things you cannot do, automatically or programmatically extracting data or output from its services. We read no other provider's terms for this guide, so check each before you script anything. Be wary of any tool that offers to "improve your score" by publishing content at scale: monitoring reports, it does not manipulate.

## Next step: set the register and run two rounds

Start with one page: 8 to 12 claims, ranked, with a desired state, two assistants and fixed conditions. Run the first round, then a second two weeks later, then switch to your normal cadence. After two rounds you know your own noise level, which every threshold depends on.

<div class="box hot"><b>If this is happening to you now</b>
<p>If a damaging claim keeps returning in AI answers and you want someone to run the rounds, apply the thresholds and own the escalation, a monthly monitoring service covers search results and AI answers on one cadence. Details are on the <a href="/reputation-monitoring">reputation monitoring</a> page.</p></div>

Reputation Partners runs this routine for clients who prefer not to hold the log themselves, and the method is open to you either way. The [AI search reputation](/ai-search-reputation) page explains the scope of that work.

## Questions people ask

### How many AI assistants should I monitor?

Start with the two or three your audience is most likely to use, and add more only when a counterparty names one. Each assistant needs its own runs and its own numbers, so the workload multiplies quickly. It is better to monitor two assistants properly than six superficially, and to record Google AI Overviews as a separate surface from chat assistants.

### How long should I keep the logs?

Keep them for at least as long as any dispute, funding cycle or regulatory matter that could involve your name, and in practice for years, since the files are small. A long record lets you show that a claim began on a given date.

### What if an assistant gives different answers on the same day?

That is normal, and the reason for ten runs per question. Report the share of runs that contain each claim, not any single answer. If the share is stable across rounds, the variation is noise around a steady pattern. If the share moves in two consecutive rounds, it is a signal worth tracing to its source.

### Should I monitor competitors or other people?

Watch your own name, your own company and those of clients who have asked you to. Following private individuals is not monitoring, it is surveillance, and it raises privacy and legal questions. For a company, comparing how assistants describe your category is reasonable, but keep the focus on claims about you and do not build profiles of named people.

### Can I automate the whole routine?

Parts of it, yes: scheduling, logging and diffing. The judgment steps should stay human, namely severity, source tracing and any content or legal decision. Check each provider's terms before you automate queries: OpenAI's terms of use bar programmatic extraction of output, and other providers differ. A hybrid, with a person owning the thresholds, is the sturdiest setup.

### When should I stop monitoring a claim?

Retire a row when the claim has held for four consecutive rounds, or when the question no longer matches a decision you make. Move a resolved critical claim to a quarterly check rather than deleting it, since a corrected falsehood can return when an old page resurfaces. Record the retirement date and the reason in the register.
