What starts the checks
Checks start when a change reaches the world:- a pull request Attensira opened is merged;
- a rewrite, an article or a copy item is marked shipped with its live URL;
- an article is published through a connector such as Notion;
- an off-site placement is verified;
- a directory listing, a profile update or a Brand Book fact carried to a profile elsewhere is read live and verified (
live_verified); its checks count from that read; - a read of one of your own pages sees a change on it, whether we shipped it, you made it from our advice, or nobody suggested it. See Page changes.
prompt_ids given to propose_fix). A shipped change with no tracked prompts attached is not checked. A change seen on your page is measured on the prompts its suggestion names, else the prompts that cited the page; Page changes has the order.
Four checks: +3, +7, +14 and +30 days
Each change is checked four times, at +3, +7, +14 and +30 days after it shipped. The +3 is an early look. It shows whether the change is live and gives an early verdict, but it is never pooled into the change’s single line and never counted in a win rate: its after-window starts the day the change shipped, so it is the least evidence of the four. The +7, +14 and +30 are the full checks, and the pooled line is argued from the +30 alone. The +3 is booked only while it can still run on time. A change whose +3 has already passed when its checks are booked (for example, a change first seen on your page more than a week after it went up) skips it rather than running it late, and gets the other three. Each check compares two windows of the prompt’s daily reading slots:- Before: the 7 slot days before the change. For a change seen on your page, the 7 slot days before the last read that still saw the old version, so the days the change may or may not have been live count on neither side.
- After: 7 slot days centred on the +N date.
n), and none is a day-over-day comparison.
Each prompt and engine pair is decided by a significance test on the two windows’ answers: a two-proportion z-test at 95% when both windows have at least 30 successful answers, and Fisher’s exact test, two-sided at p ≤ 0.05, when either has fewer. At one run a day, a week is 7 answers a side, so most checks use Fisher’s exact test. A check needs at least 5 days with a successful reading in the week before, and answers in the measured week, to be decided at all; otherwise it is Not enough answers yet. See How we collect data.
Is the change live?
Before measuring, the check confirms that the change is on the live page:- For a rewrite or copy, the exact new text must appear on the page.
- For a new article, the page must load with content.
Which market a change is measured in
When your workspace reads more than one market, a change made for one market is checked only on that market’s answers. A page written for Germany is read by German answers; counting American answers that never saw it would hide a real change behind “no change”. The market is read from the page, in this order:- A locale in the path, such as
/de/,/de-at/or/uk/. A two-letter segment followed by a number (/de/42) is a record, not a locale, and/id/,/my/,/go/and/me/are read as words;/id-id/still counts. - The hreflang your site declares for the page, from the language versions linked on your home page.
- A country-code domain, such as
example.deorexample.co.uk.
/en/ on a site read in the US and Britain says nothing about which one, so it counts every market. Domains sold as generic names (.io, .ai, .co and similar) are not read as countries. A page that names no market counts every market’s answers, as a one-market workspace always does.
The market is stored on the change with the reason the first time it is final: when the path names it, or once your home page has been read for its hreflang (a workspace with no domain declares none). Every later check uses the stored market. If the home page cannot be read, that check uses what the path and domain say, nothing is stored, and the next check asks again. A stored market your workspace no longer reads counts every market, and says so. The receipt names it, and the change shows it as target_market: market (a country code, or all), language when the market has one, source (locale_path, hreflang, cctld or none) and reason. In a workspace that reads one market, nothing changes and there is no target_market.
When a check cannot run
Checks run in one pass a night. If a check cannot run (its answers, its prompts or the change behind it could not be loaded), it is not left waiting and it is not given a verdict it did not earn. It is tried again after a growing wait: 6 hours, 12 hours, 24 hours, then 48 hours. With one pass a night, that means the nights after the first try, then two nights later. If the fifth try also fails, the check stops for good, with the reason in one sentence, for example “We could not measure this change: the answers in the measurement window could not be loaded.” Nobody has to clear it by hand: every check ends with a verdict or a stated reason, at most five nights after its first try. A check that works on a later try gets its verdict as usual. Each failed try shows in loop health as Measuring shipped changes. When more than 5% of one night’s checks fail, we treat it as a fault on our side and we are alerted. Over the API, a check showsattempts (how many tries failed), last_error (the kind of failure: workspace_unavailable, questions_unavailable, change_unavailable, readings_unavailable, store_unavailable or internal) and next_try_at while it waits for its next try. A check that could not be measured has the status unmeasurable, and its reason is the sentence.
The verdicts
These are the same words the receipt uses for each check.
Every result is a single dated reading. A Moved verdict is what lets the morning brief, the receipt and the win plan use movement wording at all.
The labels beside a page
Where a shipped change is shown against the page it changed, its check result is shown as one of three labels, all read from one map. That is the page-change card in Work, and thelast_change.verdict field on each row of the signed-in pages read (GET /v1/projects/{id}/analytics/pages), which no app screen draws now:
moved says the number moved after the change, past the significance test. It is observed movement, not proof that the change caused it: the check cannot rule out everything else that changed in the same weeks. “The windows agree” and “they differ by less than the noise” are different findings that earn the same honest sentence, so both read nothing we can prove yet. A result the map does not know also reads nothing we can prove yet, never moved.
Only the check of AI answers carries a label. Google clicks and positions and AI-crawler fetches shown around a change are counts with their own sample sizes; no verdict is drawn from them. See Google search.
What counts as a proven change
A change is proven when its check says Moved (named more often) at +14 or +30 days. The +7 check is the first look, so a move there alone does not count. Fell, No change, Too close to call, Too few answers and Not live never count: they are honest answers, but they prove nothing. The newest check with a verdict decides. If the +14 says Moved and the +30 then says Fell or Too close to call, the change stops counting as proven. A proven change counts in the month of the check that decides it. This is the number we hold ourselves to: proven changes per paying workspace per month. A change’slifecycle reads checked once any check has written a verdict, whatever it said. checked is not a claim that the change worked; the verdict is. (checked was called verified until October 2026.)
How a verdict reads
Each verdict, in its email and in the action log, opens with the windows it compared:Re-read at +14 days, read on 2026-10-06: 2026-09-15 to 2026-09-21 before the change, against 2026-09-26 to 2026-10-02 after it.
Where you see them
- Receipts: each shipped change’s receipt lists its checks with their verdicts and folds them into one verdict for the change.
- Deliverables: each shipped item shows its latest check result.
- A prompt’s detail: Before and after lists this prompt’s checks with their samples, windows and outcome. See Prompts.
- The morning brief: Next checks, at most five prompts, soonest first.
- The win plan:
rereads_atis the day the next booked check for that prompt actually runs. - Client reports: the check verdicts are the only place a client report uses movement language.