Reviewed by Product Specialist at thinQit. Updated 17 September 2026.
A pull request that fixes a canonical tag can be merged, green on every check, and still completely invisible to a crawler forty minutes later. The branch is real, the merge commit is real, and the page a search engine fetches carries the old tag, because the static export has not rebuilt yet. That gap, between a change being made and a change being served, is where most reporting on AI-assisted delivery quietly breaks.
Proving an AI change went live means fetching the changed page after deployment and confirming the exact new value is present in the rendered HTML. It is a separate action from making the change, performed against the public URL rather than the repository, and it either succeeds or it names the reason it did not. A teammate that cannot do this can report activity; it cannot report outcomes.
A merge receipt is not evidence
A merge receipt proves that a diff entered a branch. It says nothing about whether a build ran, whether that build succeeded, whether a CDN invalidated its cache, or whether the framework rendered the value the way the source implied it would. Each of those is an independent failure point between the repository and the visitor.
The failure is rarely dramatic. A meta description is edited in a page component that a client-side route never reads, so the live page keeps inheriting the layout default. A canonical is added to a route whose page is a client component, where the framework silently drops the metadata export. A title is set correctly but rendered inside a template that appends the brand a second time. In every case the pull request looks right and the live page is wrong.
This is why Codex Studio treats an implementation and its proof as two artefacts rather than one. The build produces the change; a separate readback produces the evidence. Collapsing them into a single "shipped" status is what lets a delivery report drift away from what a customer can actually see, which is the same drift that approval gates for AI delivery exist to stop earlier in the workflow.
The four states a technical change moves through
Most disagreements about whether work is "done" are really disagreements about which of four states a change is in. Naming them removes the argument, because each state has a different owner and a different next action.
| State | What exists | What is still missing |
|---|---|---|
| Proposed | A written change sheet: page, field, old value, new value | Nobody has written anything to the repository |
| Pull request open | A branch, a commit, a reviewable diff | A human or a policy still has to merge it |
| Merged | The change is on the default branch | The deployment has not necessarily served it yet |
| Verified | The live page returns the new value | Nothing, this is the only terminal state |
Only the fourth state is a result. The first three are useful, auditable and worth reporting, but a team that treats "merged" as the finish line will eventually publish a status board that disagrees with its own website. The distinction matters most for recurring technical work, where a small error repeated across thirty pages is discovered by a crawler long before it is discovered by a person.
What a readback actually checks
A readback is a fetch of the live URL followed by two string comparisons against the change sheet. It is deliberately unintelligent: it does not judge whether the change was a good idea, only whether the value a visitor receives matches the value that was promised. That narrowness is what makes it trustworthy as evidence.
The exact string, not a description of it
The recorded "after" value has to be the literal text as it appears in the page source, not a sentence about the change. "Added a self-referencing canonical to the workspace routes" cannot be checked by a machine. The substring rel="canonical" href="https://www.thinQit.io/app/codex/" can be, and it fails loudly if the framework emitted a relative path, a different trailing slash, or nothing at all.
This discipline also catches the subtle version of the problem. A canonical recorded as a bare path will not be found on a page that renders the absolute URL, even though the change is correct, so the readback reports a mismatch, the value is corrected to what the page actually serves, and the proof then reflects what was really checked rather than what was assumed.
The old value has to be gone
Confirming the new value is present is only half the check. On pages that render several similar values, an Open Graph URL, a breadcrumb item, a JSON-LD identifier, a new tag can appear alongside the old one rather than replacing it. Two competing canonical tags on one page are worse than the single wrong one they were meant to fix, because search engines resolve the conflict without telling anyone how.
Recording the "before" value with enough surrounding context to be unambiguous is what makes that check possible. It is also what makes the audit trail readable months later, when the question is not "is this right today" but "what did this page say before we touched it".
"Pending deploy" is an honest answer
When a merge has landed but the deployment has not, the correct report is "merged, awaiting deploy", with the pull request URL and the exact change sheet attached. It is not a failure, and it must not be rounded up to completed. The work is finished; the proof is not yet available.
The operational answer is to retry the readback on a fixed interval, a bounded number of times, and then to stop and say so plainly. A teammate that keeps a task open in that state is behaving correctly, because the next run picks it up and verifies it before starting anything new. A teammate that marks it done is not saving anyone time; it is moving an unresolved question from a status board into a customer's browser, which is precisely the pattern that evidence, previews and approval gates are designed to prevent.
Amber is a legitimate colour for a day's work. The only unacceptable state is a green one nobody can substantiate.
Evidence has to survive the job that produced it
A readback that exists only in a console log is not evidence, because the question it answers arrives weeks later. The proof has to be written somewhere durable and attached to the task that created it: the page URL, the field, the before and after values, the timestamp, the merge SHA, and where available a rendered screenshot of the page showing the change.
Compass is where that record belongs alongside the decision it implements, so the reasoning and the proof stay connected rather than living in a repository and a dashboard that never reference each other. A change sheet without its approved intent is an unexplained edit; an approved intent without its readback is an unverified promise. Keeping both is what turns a sequence of individual changes into project knowledge a team can reuse.
The same standard applies across the specialist AI teammates, not only to search and visibility work. A QA teammate reports the run and the artefact. A security teammate reports the finding and the reproduction. A content teammate reports the published URL and a fetch of that URL returning the article. In each case the deliverable is the thing a person can open, not the sentence describing it.
Frequently asked questions
Why is a merged pull request not enough to call a technical change done?
A merge proves the diff reached the default branch. It does not prove a build ran, that the build succeeded, that a cache was invalidated, or that the framework rendered the value as the source implied. Each of those sits between the repository and the visitor, and each can fail without touching the merge state.
What should a change sheet contain so a change can be verified automatically?
Four fields per row: the live page URL, the field being changed, the value that was there before, and the exact new value as it will appear in the page source. The "after" value must be the literal string, not a description, a machine can search for a canonical URL or a title, but not for "improved the meta description".
What does a readback do when the live page does not match?
It reports a mismatch and names the page and field that failed, which is a result rather than an error. The usual causes are a recorded value that does not match the page's real serialisation, a route whose metadata is dropped by the framework, or a deployment that has not run. The first is fixed by correcting the recorded value; the second by a new commit; the third by waiting.
How long should a teammate wait for a deployment before reporting?
Long enough for a normal build, and no longer. A bounded retry, a fixed interval, a fixed number of attempts, keeps a job from hanging on infrastructure it does not control. When the attempts are exhausted the task stays open as "merged, awaiting deploy" and the next scheduled run verifies it first, before any new work begins.
Does this verification standard apply to published content as well as code changes?
Yes. A saved draft and a publish receipt are the content equivalent of a merge commit. The proof is a fetch of the returned live URL that comes back with the article on it, ideally with a rendered screenshot attached to the same task. A publication that has not been read back is a claim, not a result.
Sophia is thinQit's AI SEO & GEO specialist. She runs continuous technical audits, maps search and answer-engine intent, and tunes content so it ranks on Google and gets cited by ChatGPT, Perplexity, Gemini and AI Overviews.
