How do I keep proof of AI changes to product listings and prices?

Save every listing change as a step with the before and after values in the step's saved result: the listing, the field, the old value, the new value, the instruction behind it, and the time. Review the receipt and actual deliverable before accepting a handover.

Last updated: 2026-10-17

Catalogue work by agents is high-volume and low-visibility: hundreds of small edits, any one of which can be the expensive one (a decimal in the wrong place, a discontinued claim in a description, a variant mapped to the wrong photo). Platform edit histories show fragments, expire, and never record the instruction. The step record is built for exactly this shape of work.

The pattern mirrors the ad-account page in this cluster, with values instead of settings. The intent is saved first where the change is material (price changes, claim language, anything regulated). The action step saves the field-level before and after as its result, committed in a receipt at execution (AER-1, IETF Internet-draft-zambo-aer1-21). Batches are saved per listing, not per afternoon: when the bad value is found, the search is by listing and field, and the answer is one step.

For the shop owner, the weekly export of listing-change steps doubles as the operations review: what changed, what the agent touched most, where approvals should be added. Price changes above a threshold and claim-language changes belong behind a recorded human approval step; the record makes that gate visible to anyone reviewing the catalogue later, including a marketplace asking how a listing came to say what it says.

Checklist: listing-change proof

Per change: 1. Listing ID and field named in the step. 2. Before value and after value in the saved result. 3. Instruction or rule behind the change (repricing rule, supplier update, seasonal copy). 4. Approval step first, where the change is a price move beyond your threshold or touches claim language. 5. Batch rule: one step per listing per change set; never one step for a whole catalogue run. Weekly: export and scan the change steps; investigate any change with no instruction recorded.

Worked example

Sample: a marketplace queries a health claim in a description. The change step shows the claim entered on a dated supplier-copy update, before value without the claim, after value with it, instruction recorded as the supplier sheet. The fix is one step, the answer to the marketplace is the record, and the approval gate for claim language is added the same day. (Sample scenario; no live record is cited.)

Frequently asked questions

Our catalogue has thousands of listings. Is per-change recording realistic?

The recording is automatic where changes run through the connection; the discipline is granularity, one step per listing change set, not manual paperwork. Volume is the argument for the record, since no human reviews thousands of edits by reading.

The marketplace has its own listing history. What does the step add?

The instruction, the approval, and portability. Marketplace history stays inside the marketplace and shows the change without its reason; the step record holds all three and travels with your business records.

What about price changes the agent makes under a rule I set?

The step names the rule as its instruction, which is the correct attribution: the agent executed, the rule decided, you set the rule. When a rule misfires, the steps show every listing it touched, which is the rollback list.

By Brennan Zambo, founder of Zambo.

Last verified: 2026-10-17.

Put the next catalogue run on per-change steps: https://zambo.dev/demo/ .

Try a handover

A handover gives your client one proof link with verifiable receipts to review, then Accept or Flag.

try it: say 'use zambo to hand this over to <client>' in your ai

Add Zambo · Handover docs · Real public handover · AER-1