The QA mindset: evidence, verification, and knowing when something is done

A catalog change is any edit to how a marketplace describes or sells your product — a new title, a corrected weight, a different price. Every change passes through three states; problems hide in the gap between the last two.

1. Requested — the value should change and you know its source.
2. Submitted — you sent it in (an edit form, a spreadsheet upload, or a feed — a machine-readable file sent to the marketplace) and received a processing result: accepted, rejected or partly processed.
3. Verified — the live page, in the marketplace and language you changed, shows the new value as a shopper sees it. Amazon 3P → Listing maintenance calls these baseline, submission and verification.

A success message describes the file, not the page. "Processed without errors" means the marketplace could read what you sent, not that the page changed: a higher-ranked contribution (another party's content for the same page) may win, a review may hold the change, or the value may land in a field nobody sees. Only the page settles it.

Every value you submit should trace to an approved source: a record the product's owner has signed off. Approved sources: the brand's specification sheet, the packaging, the GS1 record for the identifier (GS1 is the standards body behind barcodes), and the compliance sheet for warnings and country of origin.

Not a source:

• a competitor's page or any other listing;
• an old version of your own listing, which may carry the error you are fixing;
• an email that mentions a value without anyone confirming it;
• your memory, or a colleague's.

A blank is missing information, not permission to guess. When the source has no value, ask the product owner rather than supplying a plausible number. A guessed weight becomes a fact the moment it goes live.

Record the source next to the value. A column naming each value's origin (spec sheet v3, page 2) turns a later dispute into a lookup and shows whoever inherits the work what to trust.

Evidence is anything that lets someone who was not there see what you saw. Collect it as you work; pages change and results disappear.

Always keep:

• a before and an after screenshot, each dated;
• the submission ID (the feed, batch or upload reference);
• the case or ticket ID, if you opened one with the marketplace's support;
• the exact field name as the marketplace labels it, and both values, submitted and displayed.

Keep one issue per record. A row saying "title, image and price wrong on three items" cannot be closed; its parts resolve on different days, by different people. Nine rows can.

Evidence is also what gets a case acted on. The reader has minutes and no context: a field name, two values and a dated screenshot let them act at once; "the listing looks wrong" earns a request for more detail and a week's delay. Walmart 1P → Issue resolution and each platform's case module cover the mechanics; the evidence is the same everywhere.

Answer four questions first; a minute saves days.

1. Which layer? Identity (the record), content (title, images, attributes), offer (price, quantity) or page; Foundations → Anatomy of a listing defines them.
2. Whose contribution is showing? On a shared page the value may be another seller's, the brand owner's or the marketplace's; if not yours, resubmitting changes nothing.
3. Who owns the fix? You, through an edit or a file; the brand owner; or the marketplace, through a case. Ask only the party who can act.
4. Is it the file or the catalog? Wrong in your file, or rejected in the result: fix and resubmit. Right in your file, accepted, yet wrong on the page after the processing window (usually hours; days where a review applies): a catalog problem the same file will not move.

The wrong layer wastes work: rewriting bullets for an item nobody can buy because its offer is inactive, or a case over a typo in your file. Walmart 3P → Catalog fundamentals applies the same habit with three buckets: content, offer, publishing.

A short weekly review keeps the submitted-to-verified gap visible:

• counts by state;
• open items by owner;
• anything submitted for longer than your limit, say seven days: overdue for verification or escalation.

Definition of done: verified on the live page and logged with its evidence. One without the other is not done. Amazon 3P → Reports and catalog health runs the sweep that catches what the loop missed.

Five steps, every time:

1. Define the change: item, field, old value, new value, source.
2. Submit through the right channel for that layer.
3. Read the processing result and fix any rejection at its cause.
4. Verify on the live page, as a shopper, once the processing window has passed.
5. Log and close, or escalate with the evidence to the fix's owner.

To hand work over, pass the log, not a summary: open items with state, owner, source and evidence let the next person continue without redoing the diagnosis.