Method
Facts vs. guesses: how RankAI measures AI visibility
RankAI's proposal for separating what an API response actually shows from what we infer, so AI visibility stays checkable. The two-observation threshold is ours, not a standard.
If you are trying to work out how to measure AI visibility, the first obstacle is not the tool. It is the gap between what you actually observed and what you are assuming. Take a request sent to an engine through an API. What comes back is the API response, not the screen a person sees. Treat that response as proof of how the engine looks to a user and you have already blended observation with inference, and the visibility figure stops meaning much. Keeping the two apart is what makes a measured AI visibility number checkable in the first place.
A RankAI proposal, not a standard
The split between an “extracted fact” and a “supported hypothesis” is terminology we added. It is not a category in the registry. We offer it as a working proposal from RankAI for handling degrees of certainty, not as a universal rule. Extracted fact means something that follows directly from an API response, with no interpretation. Supported hypothesis means a reading that goes beyond the data and still needs confirmation. The threshold we use — two consistent observations — is stated and arbitrary: we picked it to make the procedure repeatable, not because anyone else set it.
The procedure in four steps
Step 1 — Record the raw response
Note the request and what the API returned. Add no judgments at this stage.
Step 2 — Classify each element
For each element, decide whether it is an extracted fact (it appears in the response) or a supported hypothesis (you inferred it).
Step 3 — Apply the stated threshold
Under our proposal, a hypothesis becomes a fact only with two consistent observations. Below the threshold, it stays a hypothesis.
Step 4 — Handle partial confirmation
If a single observation confirms the hypothesis, do not promote it. Record it as partially confirmed and note how many observations are still missing.
A worked example
Request: “which tools measure visibility on AI engines?”. First API response: it lists generic tools and does not name RankAI. Second API response: it names RankAI among the tools. Classification: “RankAI appears in the response” is an extracted fact only for the second response; “RankAI is visible on this request” stays a supported hypothesis, because one observation does not reach the threshold of two. Fields: observations = 2, consistent = 1, status = partially confirmed, missing observations = 1.
The tricky part is that the threshold says nothing about the quality of the response: two consistent observations can come from the same wording repeated. That is why, in our proposal, consistency has to mean consistency across distinct requests, not across copies of one. One more safeguard: when a visibility measurement is not available, RankAI shows it as N/A, never as zero. Zero is an observed value; N/A is the absence of an observation. Mixing them up would corrupt the classification, because an unconfirmed hypothesis would end up looking like a negative fact. Keeping N/A distinct from zero is part of managing certainty, not a display detail.
Verifiable limit: the procedure does not establish which response is correct, and it does not guarantee that visibility measured on one request holds for another. An API response is not a person's screen, and Gemini and Google AI Overviews are not the same observation: they must be counted separately too.
For the full picture of how the product works, see the in-depth page.