How the score is measured

Every answer is a real, stored response

An audit asks AI engines the questions a real customer would ask when looking for a business like yours, then records who each engine recommends. The answers are stored verbatim, and everything in a report is read from that stored record. We never fabricate, simulate, or paraphrase an answer.

Each probe is labeled with exactly what it is: the API it called and the grounding method it used. OpenAI (web search), for example, means the OpenAI API with its web search tool turned on, not the ChatGPT app. Consumer apps layer personalization and memory on top of these APIs, so we never claim a probe is the app itself; the APIs are the closest measurable, reproducible proxy. The Claude probe runs its web search on the Sonnet model.

The same questions for everyone

Every audit runs a fixed matrix of query templates, filled in deterministically from the business profile (category, neighborhood, city) the way the probe above asked for “best pizza restaurant in Temescal”.

The same profile always produces the same queries, so two businesses in the same category are measured with structurally identical questions and their scores are comparable.

We publish the structure and the weights, but not the verbatim query strings. If the exact probes were public, a score could be gamed by optimizing for those literal sentences instead of for genuine visibility, and the measurement would stop meaning anything. Search engines publish ranking principles, not their crawlers’ probes, for the same reason.

Three matrices, one shape

A generic matrix would ask nonsense of a law firm (“best lawyer for a special occasion”), so verticals whose customers ask differently get a matrix of their own. Each one keeps the same four intent families, the same counts, and the same weights. What changes is what each family means for that kind of business.

When a vertical is added, the matrix is published here in the same form before the first audit runs on it: its shape, its weights, and one example. The verbatim set stays private for the reason above.

How the score is computed

For each engine, every query contributes to a score from 0 to 100. Three quantities determine each query’s contribution:

rank_weight

Where the engine placed you. Position 1 counts 1.0, position 2 counts 0.7, position 3 counts 0.5, positions 4 and 5 count 0.3, anything deeper counts 0.15, and not mentioned counts 0.

sentiment

How the answer characterizes the business, from −1 to +1, rescaled so a neutral mention still earns half credit.

intent_weight

The weight of the query’s intent family in the matrix: how much that kind of question matters to a real customer.

Queries where the business was not mentioned stay in the denominator, so absence costs points. The headline score is the simple mean of the per-engine scores, over the engines that actually completed. An engine that failed to run is excluded, never averaged in as a zero.

Grades map directly from the blended score: 80 and above is an A, 60–79 a B, 40–59 a C, 20–39 a D, and below 20 an F.

The AI classifies; code computes

A language model reads each stored engine answer and classifies three things: whether an entity is present, at what rank, and with what sentiment. It also writes the plain-language prose in the report. Everything numeric comes from code: the query matrix, the intent weights, the score, the grade mapping, and the gap detection triggers are deterministic arithmetic over stored values. Run the same stored answers through the pipeline twice and you get the same score twice.

What counts as a gap

A report names your top three gaps. Each one is detected by a fixed rule over stored data, never by an AI deciding what looks wrong. The AI only writes the sentence that explains a gap the code already found, and every gap quotes the stored evidence it was found in.

citation_source

The engines cite sources when they answer, and your own site is not among them often enough. Fires when your site is cited in fewer than 33% of the answers that cite anything. The report lists the domains the engines did cite, counted per stored answer.

places_profile

Your Google Places profile, as stored at audit time, is missing a field the engines draw on: the website, the neighborhood, or both. No threshold; a missing field is the gap.

review_delta

A named competitor on your leaderboard has at least 2× your review count, or a rating at least 0.3 stars above yours, from the same Google Places snapshot. The headline names which condition fired; the evidence quotes both numbers.

accuracy

An engine stated one of your listing facts and code graded it wrong against your Google listing. Fires on at least one wrong fact and then ranks first. Not stated and unclear answers never fire it.

A gap that does not fire is not shown. If your rating leads the field, the report says so rather than inventing a deficit.

The noise floor was measured, not chosen

AI engine answers vary between runs even when nothing about a business changes. Before treating any score movement as signal, we measured that variation directly: repeated audits with an identical configuration, across multiple days.

We treat a change of fewer than 10 points on the blended score as noise, not news. That threshold is two audit-to-audit standard deviations, rounded up. This is why a report will never alarm you over a 9-point dip: if we tell you your visibility dropped, the movement cleared a bar that random variation does not clear.

We ask one question twice

The noise floor above says how much a whole score moves between identical audits. It does not show you the instability itself. So every audit asks its first question a second time and reports what came back.

A free audit asks twice on Gemini (Google Search grounding). A Pro audit asks twice on OpenAI (web search), Gemini (Google Search grounding) and Claude (web search). The second ask uses the same question text, the same engine and the same UTC day as the first, under a distinct cache key so the second ask can never be served the first ask’s stored answer. If the two asks would land on different UTC days, no reading is stored: two days of engine behaviour is a different measurement, and we would rather show you nothing than something we cannot defend.

What we compare is the set of businesses each answer named. The stored figure is the intersection of the two sets over their union, the Jaccard index, computed in code from the names the classifier matched in each answer. Your report card shows the counts rather than that ratio, because a percentage from a single pair of answers is not a rate. Names are compared after the same normalization the rest of the instrument uses, so a respelling is not counted as a different business.

The second answer is never scored. It is not in your blended score, not in your leaderboard, not in your gaps, and not in the answer count on your report. It exists only to tell you how stable the first one was. That separation is why the stability reading can never move your grade.

The figure the panel cites for score movement is our own: run nf-2026-07 measured an audit-to-audit standard deviation of 4.73 points on the blended score, which rounds to about 5 points between identical asks and sets the 10-point reporting bar above. We publish no average overlap across audits yet. That number needs enough stored pairs per engine to be an average rather than an anecdote, and when it exists it will be computed from the stored readings, not estimated.

Five facts, graded in code

Being recommended is not enough if the answer then gets your details wrong. So every audit also asks five plain questions about your business: its opening hours, its phone number, its address, what kind of business it is, and its website. Each question carries only your business name and your town, never the phone number or the hours themselves, so the question cannot hand the engine its answer.

A free audit asks them on Gemini (Google Search grounding). A Pro audit asks them on OpenAI (web search), Gemini (Google Search grounding) and Claude (web search). Answers are stored and cached the same way as every other answer on your report.

A language model reads each answer once, separately, and reports only whether the answer states the fact, the exact words it used, and how sure it is. It never sees what Google lists, so it cannot lean toward agreeing. A claim it reports is used only when it can be found in the stored answer: either as one unbroken stretch of the answer, or, when the model joined lines of a list, with every number in it appearing in the answer in the same order and most of its words appearing too. A number the answer never gave always fails.

Code then compares that claim with your Google listing, frozen when the audit ran. Google’s listing is refreshed when it is more than seven days old, so the version used is never more than a week older than the audit:

• Hours agree when every day the answer names matches Google within 15 minutes on each opening and closing time. Any contradicted day is wrong; a partial schedule with no contradiction counts as correct. Only regular hours are checked, not holiday hours.
• A phone answer is correct when any number it gives matches the last ten digits of the listed number, and wrong only when it gives numbers and none of them match. An answer covering two locations is not marked wrong for naming the other one too.
• Addresses agree on the street number and a shared street name. Suite, city and zip are ignored.
• Websites agree on the registered domain, or on the page itself for social and booking hosts.
• Category counts as correct on a shared word with the category Google lists. Anything else is unclear. This version of the grader never marks a category wrong.

Each fact ends in one of four verdicts. Correct and wrong are the comparison above. Not stated means the answer did not give the fact, said it did not know, or sent the reader somewhere else. Unclear means code could not decide: the model reading the answer was less than 0.7 sure, the claim could not be found in the answer, or there was nothing to compare it with. That floor is a number we chose, not one taken from a study; the first real rows will tell us whether it is too tight.

The headline on your report counts correct facts out of every fact except the unclear ones. Not stated counts against the engine: an assistant that cannot state your phone number cannot act on it for a customer. Unclear answers are shown with their words and left out of the count. None of this is part of your AI Visibility Score. It sits beside your grade and never moves it.

The comparisons have their own version, stamped on every stored verdict. The current version is 2026-09-30.1. We cite no outside study for any of this; every figure here is either a rule in our code or a count from your own audit.

1. 2026-09-30.1

   D90

   Fact grading begins. Hours agree when every day the answer names matches Google within 15 minutes per opening and closing time; a partial schedule with no contradiction counts as correct. Phone numbers agree on their last ten digits. Addresses agree on the street number and a shared street name, ignoring suite, city and zip. Websites agree on the registered domain, or on the page for social and booking hosts. Category counts as correct on a shared word and is never graded wrong in this version. A claim the extractor is less than 0.7 sure of, or that does not appear word for word in the answer, is shown as unclear and left out of the count.

An audit never changes

An audit is an immutable snapshot. The engine answers, mentions, scores, and gaps are stored once, and a report URL renders from those stored values forever. Nothing is re-generated when someone opens the report later.

Every audit is stamped with the engine version at the top of this page. When the instrument changes materially (probe models, answer extraction, the analyzer, or the scoring math), the version is bumped, and audits from different versions are never compared for alerts. A cross-version difference is a change in the instrument, not in your visibility.

What an audit costs

Real answers cost real money. Every probe is a paid API call with web search turned on, and we publish the bill so the limits on the free tool read as arithmetic rather than a sales tactic.

That is why the free tool has limits: 5 audits a day per visitor, 150 a day for everyone, and a daily spending breaker that pauses new audits before the day’s budget is gone. Pro raises the personal cap to 10 and adds a weekly re-audit of one business.

Every version of the instrument

Each entry is a version that was stamped on real audits, what changed, and why scores across the boundary are not compared. The current version is 2026-08-26.1. A version cannot ship without its entry here: a test fails if the two disagree.

1. 2026-07-18.1

   D27

   Versions begin. The noise floor was measured (run nf-2026-07) and the movement threshold was set from it at 10 blended points. Every audit from here on carries its version.

   Not comparable because: Audits before this date carry no version and are never compared for alerts.

2. 2026-07-29.1

   D28

   Estate-planning attorneys got their own query matrix, place names in legal queries gained their state, and an engine that returned nothing scoreable is dropped from the blend instead of counting as zero.

   Not comparable because: A blended score with a dropped engine is a mean over fewer engines than before.

3. 2026-08-25.1

   D57

   Claude (web search) became the third engine. The blended score is now a mean over three engines.

   Not comparable because: A three-engine mean and a two-engine mean measure different things. This version was stamped only on internal audits; it was replaced the next day before any public report used it.

4. 2026-08-26.1

   D57, D58

   Every place name in the generic matrix now carries its parent (neighborhood with city, city with state), because location-blind engines answered for the wrong metro. Shipped together with the third engine so public reports saw one instrument change, not two.

   Not comparable because: Changed query text changes what the engines are asked, so answers before and after are different measurements.

Copy and design changes to this page do not bump the version; only changes to what is asked, how answers are read, or how the score is computed do.