Why Verification Must Be Independent From the Agent That Made the Change

The executor knows what it intended

An execution agent writes:

compatibility_metafield =
"Dual display on Apple silicon requires DisplayLink Manager."

Shopify returns success. The agent reports that the task is complete.

But several things can still be wrong:

• the Theme does not render the metafield
• a translation displays the old value
• the wrong market or product revision was edited
• JSON-LD describes another variant
• a feed still uses old content
• the page is cached
• the change breaks layout on mobile

The API response proves only that the write request was accepted.

Independence reduces confirmation bias

The verifier should not receive “the fix worked” as a fact. It receives:

• original finding
• approved change record
• expected public state
• affected products and markets
• regression scope
• before-observation IDs

It then performs fresh retrieval.

This is similar to separating code implementation from acceptance testing. Different tools, context, or process can expose assumptions made by the executor.

Verify at several layers

Deployment

Did the intended value publish to the right Shopify object?

Public storefront

Is the value visible on the canonical page, in the correct market and selected variant?

Machine-readable state

Do Product and Offer JSON-LD, variant data, and connected feeds remain consistent?

Commerce behavior

Do price, stock, cart, subscription, shipping, and policy behavior still work?

Observation contract

Can the same buyer question be rerun with the same prompt ID, market, expected facts, and evidence fields?

Failures are not non-mentions

If the provider times out during the post-change run, the verifier records provider_failure. It does not report that the store disappeared.

If the page returns 200 but contains a challenge, the verifier records unusable content. It does not report retrieval success from the status alone.

Verification can pass before visibility changes

The fix can be correctly deployed and verified even when no later AI citation is observed.

Example:

Public compatibility fact: verified
Structured product identity: verified
Feed refresh: accepted
Fixed prompt run: completed
Canonical citation: not observed

This distinction prevents the team from undoing a correct product-information repair simply because an independent platform did not change immediately.

The output becomes a new baseline

Verification records the corrected state and any remaining uncertainty. Future monitoring compares against that state.

The release, evidence, and post-change observations then move to Attribute, where the question changes from “did it deploy?” to “what later outcomes can be associated with it?”