Did It Land? — Live-Surface Change Verifier for Listings, Prices, Profiles & Catalogs

"The price is updated." "The listing is fixed." "Your profile now says…" "The book page shows the new description." On live surfaces — a marketplace listing, a seller profile, a book catalog page, a storefront, a dashboard-driven directory — a dashboard confirmation is not evidence. The edit screen says saved; the buyer-facing page may still show the old price, a sale-event overlay may change the total the buyer actually pays, the change may have landed on the wrong variant or edition, a cached or flattened text read may hide the rendered state, or the identifier you verified may not be the identifier that is live.

Code-change verifiers exist for repositories: checkpoint, smallest edit, run the tests, inspect the diff. They cannot help here, because a marketplace listing has no test suite and a catalog page has no diff. This skill is the change-verification discipline for live, human-facing surfaces: lock the canonical target and intended values before the change, capture a rendered baseline, record the access route that actually reaches the live surface, read the rendered surface back after the change, diff intended vs observed, check for collateral movement, and issue one of five honest verdicts — never a bare "done."

Built from a live operation where change claims caused real damage: prices reported updated that had never moved on the buyer-facing page, a catalog split under two name variants where edits landed on one and were reported for both, a portal confidently declared absent that the owner opened himself in seconds, and flattened text reads that missed what the rendered page actually showed.

• After any edit to a live listing, price, profile, catalog entry, storefront, directory page, or dashboard-driven record — before reporting the change as done.
• When a platform shows "saved," "published," or "approved" but nobody has seen the change on the surface a buyer, reader, or customer sees.
• When a change was made by someone else (a teammate, a delegated agent, a platform automation, a sale event) and its real effect needs proving.
• When the user disputes a "done" report, or a previous change report turned out wrong.
• As a standing gate: any completion claim about a live surface ("updated," "fixed," "live," "corrected") in a report must pass this workflow before the report ships.