Answer Radar
Verifying a Fix: Re-Measurement After a Change
After you publish a change, the honest question is not 'did it work' but 'what moved'. Re-verification re-measures the same buying questions with the same configuration after a delay, pairs the result with the baseline on the same instrument, and reports movement. It never reports a cause, and it says so in every response.
Quick Answer
answer_verify_start registers a re-verification for a gap and optionally the fix being tested. It starts no run now; the follow-up is due after an indexing delay, 168 hours by default. answer_verify_get returns the report once the follow-up settles, with an outcome per segment: improved, declined, mixed, no_significant_change, not_comparable or ambient_change_not_isolated.
- A null report means not measured yet, never no change.
- Presence rate and recommendation rate are compared; share of voice and position are not.
- A change counts only when it clears both a minimum and the smallest change the sample size can express.
On this page
Why the delay
Content published today is not retrievable today. An immediate re-measurement would report no change about something nothing has seen yet. So registering a re-verification starts no run; it records what to re-measure and when the follow-up is due, followup_due_at, one indexing delay from now. The configured default is 168 hours. Poll answer_verify_get after that time.
What is compared, and what is not
The follow-up uses the identical prompts and configuration as the baseline. Segments are paired only when provider, model, tool version, geography and language all match; a segment present on one side and not the other is not_comparable, never a fall to zero, because a model or tool-version change means the two runs used different instruments.
Two metrics are compared: presence rate and recommendation rate, both per-sample ratios on identical denominators. Share of voice is a distribution and mean position is an ordinal whose absence is not zero, so neither is subtracted.
When a change counts
A rate over n samples can only take values k over n, so its resolution is 1 over n, taken from the coarser side. The threshold applied is the larger of the configured minimum change, 0.10 by default, and that resolution. A delta is significant only when its absolute value clears the threshold; anything under it is reported as no_significant_change however large it looks. Each delta carries its own smallest detectable change and the threshold applied.
No confidence value is reported. None is computed, and a plausible-looking number there would be the most quotable thing in the response.
Control prompts and the six outcomes
Control prompts are the project's other prompts, the ones the change did not target. If they moved as much as the target, the outcome is ambient_change_not_isolated: the measurement cannot separate your change from whatever moved everything. When a gap has no prompt there is no target and therefore no control set, and the report says so rather than treating every other prompt as a control.
Outcomes are about movement only. Improved and declined mean the compared metrics crossed the threshold in one direction; mixed means they crossed in different directions and is never collapsed to one; no_significant_change means both sides were measured and nothing moved beyond what the instrument can resolve; not_comparable means nothing was measured against anything. There is no field in which a cause can be recorded.
- Register right after publishing; the delay is counted from then.
- Pass the fix id so the report records which fix was being tested.
- Keep the prompt set unchanged until the follow-up settles.
FAQ
Can I shorten the wait?
The delay is configuration, not a per-request option, and it exists because an early re-measurement produces a false no change. If you re-run an audit manually sooner, that is a new run, not a paired follow-up.
My target moved and the outcome is ambient_change_not_isolated. Did the fix fail?
Neither failed nor succeeded. The controls moved as much as the target, so the movement cannot be attributed to your change. Wait for another cycle, or narrow the target prompts so the controls are clearly unrelated.
Why is a segment not_comparable?
Usually because the provider changed its model or tool version between baseline and follow-up, so the two sides are different instruments. Sometimes because one side had no admissible samples. Either way it is not a delta of zero.
Related help pages
Answer Radar
Drafting a Fix From the Evidence
How a fix goes from evidence skeleton to approved artifact: draft, write, check, save, review. What the faithfulness guard rejects and who can approve.
Answer Radar
Reading the Visibility Metrics
What presence rate, recommendation rate, share of voice, sentiment mix and citation share mean, which samples count, and why a segment can report no number.
Answer Radar
Segments and Topics: How Results Are Grouped
Why every metric is reported per segment and never averaged across engines, what the five axes are, what the instrument token is, and how topics group prompts.
Answer Radar
What Answer Radar Does Not Do
The honest list: no prompt volume, no traffic attribution, no causal claims, no consumer-app reproduction, no written briefs, no publishing, no model ids,.