The Listing Said 32oz. The Bottle Said 1 Liter. A Product-Truth Postmortem.

Postmortems on this blog follow one rule: real failures, from systems I actually run, with the fix encoded so it can't happen twice. This one is about the most common class of AI generated product content errors — an agent confidently writing marketplace copy from an unverified description of the product — and it happened on a live Amazon account I'm responsible for.

What happened

The brand is Ecolosophy, a plant-based cleaning concentrate I run the commerce stack for. The physical product is unambiguous: a 33.8 fl oz / 1 liter aluminum bottle, and the Starter Kit ships with three 16 oz aluminum sprayers. The label literally reads "33.8 FL OZ | 1 LITER."

A batch of Amazon listings generated on May 7 said something else. Every title in the batch read "32 oz." The bullets described the sprayers as "BPA-Free... Reusable Plastic Bottles." One kit even carried a size attribute of "8 Fl Oz (Pack of 4)" — a value that corresponds to no product we sell in any configuration. Four in-stock SKUs went live carrying those errors.

Here's the detail that makes this a proper agent-fleet postmortem rather than a typo story: the listings created before May 7 were correct. They said 33.8 fl oz. The May 7 batch was a regression — a generation run that worked from an approximate mental model of the product ("it's a roughly quart-sized cleaning bottle, sprayers are probably plastic like everyone else's") instead of from verified product facts. The agent didn't malfunction. It did exactly what generation does when the input is a plausible description rather than a checked one: it produced fluent, confident, wrong copy.

The bitter irony sat in plain sight the whole time. The SKU codes themselves contain the string 33.8OZ. The pipeline generated a title saying "32 oz" for a SKU literally named CITRUS-33.8OZ-STARTER-KIT.

How the error was caught

Not by a customer complaint, thankfully, and not by rereading the copy — rereading generated copy mostly confirms that it reads well, which is exactly the trap. It was caught during prep for an inbound FBA shipment, when the listings were checked against independent sources of product truth. Three separate sources contradicted the titles at once:

1. The PRODUCT-TRUTH file — a verified product-facts document maintained for the brand's ad studio, which states 33.8 fl oz / 1L aluminum.
2. The SKU codes — which encode 33.8OZ in their own names.
3. The bottle artwork — the actual label files, which read "33.8 FL OZ | 1 LITER."

That's the mechanism worth stealing: the error wasn't caught by looking harder at the output. It was caught by triangulating the output against sources the generator never touched. Any one of those three checks would have flagged it. The generation run consulted none of them.

The cost of wrong product data on a live marketplace

I won't invent a sales number — I don't have a clean before/after and this blog doesn't do fabricated metrics. But the costs that are documented are enough to justify the fix several times over:

Every listing was a standing misrepresentation. A customer comparing per-ounce value got a wrong denominator. A customer who cares that the sprayers are aluminum, not plastic — which for this brand is a core differentiator — was told the opposite of the truth. Wrong product data on a marketplace isn't a cosmetic bug; it's a claim you're making to every visitor, in writing, around the clock.

It's also a policy exposure, not just a reputation one. Amazon's Selling Policies and Seller Code of Conduct requires sellers to "provide accurate information to Amazon and our customers at all times," and states plainly that violations "may result in actions against your account, such as cancellation of listings, suspension or forfeiture of payments, and removal of selling privileges." The Product Detail Page Rules say the same thing from the other direction: sellers must "accurately categorize and describe" products, and failure to comply with listing standards "may result in your selling privileges being temporarily or permanently removed." An agent that improvises a size isn't just writing bad copy — it's generating account-health risk on autopilot.

Wrong product data is a documented driver of returns — and returns are not cheap. Peer-reviewed work on online markets (Hong & Pavlou, Information Systems Research) finds that product fit uncertainty — the buyer's inability to tell whether the product's attributes match what they need — has a significantly stronger effect on product returns than uncertainty about quality. A wrong size and a wrong material are exactly that: attribute information the buyer relied on and got wrong. And the industry-level stakes are enormous — the National Retail Federation projected total retail returns to reach $890 billion in 2024.

Overpromising feeds a returns-and-reviews spiral. A separate Information Systems Research study of a multichannel retailer found that when products are displayed with information that inflates expectations — in their data, an average rating shown higher than the true rating — those products are returned more often; and consumers who return products are more likely to write reviews, which skew more negative. Listings that overstate the product don't just cause returns; they seed the reviews that depress the next thousand sessions.

The fix was far more expensive than the generation. When we corrected the listings, the size turned out to live in five structured places per SKU — item_name, item_display_volume, item_volume, liquid_volume, unit_count — plus free text in the description, bullets, and liquid-contents fields. A first repair pass that patched only three of them left the listings self-contradicting: title saying one size, attributes saying another, which is arguably worse than being consistently wrong. Getting all four live SKUs clean and verified took a purpose-built script against the SP-API, because the off-the-shelf tooling in the pipeline could only patch price and quantity.

The error had already propagated. This is the compounding cost of AI generated product content errors: wrong data doesn't stay where it was generated. The same class of unverified-fact failure surfaced in dosing copy across the brand's own site — a dilution figure that was wrong by 3x had spread from one source document into the FAQ, the support chatbot, a recipe page with roughly twenty recipe cards, a second how-it-works page, and two blog posts. One unverified fact, seven downstream surfaces. Cleaning it up meant a full sweep of all 19 sellable SKUs plus a site-wide correction pass.

That's the real bill for skipping verification: not one wrong title, but an ecosystem of mutually reinforcing wrong copy that then looks consistent when you spot-check it.

The permanent fix: PRODUCT-TRUTH first

The fix that matters isn't the repaired listings — it's the doctrine that makes the failure structurally impossible to repeat. It has two halves.

1. No generation before a verified product-facts file exists

Every brand in my fleet now carries a PRODUCT-TRUTH.md: a single verified file containing the facts an agent is never allowed to improvise — sizes, materials, dosing, usage ritual, claims that are substantiated versus claims that are not. "Verified" means checked against physical reality: the label artwork, the actual measured dose, the real usage videos. This file gets written before the first asset is generated, not reconstructed after the first incident. It was born from an earlier failure in the same family, where generated imagery showed the product being used in a way it's never used — I wrote that one up in the hallucinated product data postmortem.

2. Every generated asset is checked against it before shipping

The second half is the gate. Generation output — listing copy, ad imagery, site copy, video scripts — gets diffed against the truth file before it touches a live surface. Not "reread it and see if it sounds right." Checked, fact by fact, against the file. In this incident, a single grep for "32 oz" against a truth file saying 33.8 would have stopped the whole batch. This is the same principle I laid out in the verification gap in production agents: agents fail politely, so the check has to be structural, not vibes-based.

And one operational corollary the multi-field repair taught me: the truth check applies to fixes too. When you correct marketplace data, enumerate every field the fact lives in before you patch any of them. A partial fix that leaves a listing disagreeing with itself is a new bug wearing the costume of a resolution.

The micro-lesson: agents don't know your product. They know your prompt.

Generalize this beyond one bottle. A language model has no sensory access to your product. It has never held the bottle, read the label, or measured the capful. Everything it "knows" about your product is whatever made it into the context — and if the context contains an approximation, the output will state that approximation with the same fluent confidence it would state a verified fact. The failure mode isn't lying; it's plausibility filling the gaps you left. "32 oz" is a completely plausible size for a cleaning bottle. That's precisely why no human skimming the copy flagged it.

So the operator's job splits cleanly in two: agents own fluency, you own facts. The facts have to exist in a verified, versioned, single-source file — and the pipeline has to be built so that generation cannot run without it and output cannot ship without being checked against it. If you're running agents against a store or marketplace, this gate belongs in your pipeline before your first listing goes live, not after your first correction sweep — it's a core chapter of my one-person e-commerce ops playbook.

The model's confidence is constant. Your data's accuracy is not. Build the gate at the point where those two things get confused.

FAQ

What causes AI generated product content errors like this?

Generation running ahead of verified product facts. The model fills gaps in its context with plausible values — a plausible size, a plausible material — and states them with full confidence. In this incident, the agent wrote "32 oz" for a 33.8 fl oz / 1 liter product and called aluminum sprayers plastic, because nothing in the pipeline forced it to consult the actual product facts first.

How do you catch wrong product data in AI-generated listings?

Triangulate against sources the generator never touched. This error was caught by checking the listings against three independent references at once: a verified product-facts file, the SKU codes themselves (which contained the correct size), and the label artwork. Rereading the generated copy alone would not have caught it — it read fine.

What is a PRODUCT-TRUTH file?

A single verified document per brand containing the facts agents may never improvise: sizes, materials, dosing, usage steps, and which claims are substantiated. It's verified against physical reality (label artwork, measured doses, real usage footage), written before the first asset is generated, and every generated asset is checked against it before shipping.

Why was fixing the Amazon listing harder than generating it?

Because the wrong size lived in five structured fields per SKU plus three free-text fields, and the available tooling could only patch price and quantity — the fix required a custom script against the SP-API. A first pass that patched only some fields left the listings contradicting themselves, which forced a second full sweep across all 19 sellable SKUs.

Does this only apply to Amazon listings?

No. The same unverified-fact failure propagated into the brand's own site — a dosing figure wrong by 3x spread into the FAQ, support chatbot, roughly twenty recipe cards, a second how-it-works page, and two blog posts. Any surface an agent writes to needs the same truth-file gate: marketplace listings, ad creative, site copy, video scripts, support bots.

— Italo Campilii. If you're building something that needs this kind of operator, get in touch.