AI Catalog Enrichment: The Review Gate Before You Publish

What “ai catalog enrichment” means once you have 4,000 SKUs, not 40

AI catalog enrichment is the use of a language model to draft product attributes, descriptions and taxonomy placement from a catalogue’s existing data instead of a merchandiser typing each field by hand. For a brand doing $3M–$30M in revenue, running Shopify Plus or a comparable paid subscription platform, the appeal is obvious: a new supplier drop of 400 SKUs used to mean a week of manual entry, and a model can draft titles, bullet descriptions and category placement for that drop in an afternoon. The problem this article covers is not whether the model can write plausible copy. It can. The problem is what happens when a merchandiser, tired at 4pm on a Friday, approves a batch without checking which fields the model actually knew and which ones it guessed.

That distinction, between a fact the model read and a fact the model inferred, is the entire subject of this piece. If you already run this process well, most of what follows will confirm what you do. If you do not yet have a review gate, use the five-column template in this article: copy it, fill it in with your own attribute classes, and run it on your next catalogue import.

This article is not written for a brand still entering products one at a time in a spreadsheet. Below roughly $3M in revenue, or without a subscription commerce platform behind the catalogue, the volume that makes AI enrichment worth the governance overhead usually is not there yet, and a manual process with a second pair of eyes is still the cheaper, safer option.

The template: a five-column review sheet for every generated field

Here is the liftable part. Build one sheet, one row per attribute class your catalogue uses, five columns. Fill the “source of truth” and “who signs off” columns with your own team’s names and systems before you run it on a real import.

Read that table as a decision rule, not a reference chart: any attribute in the “No” rows should never be a field the model is asked to originate, only a field it is asked to rephrase from a document you hand it. The two “Yes” rows are the only fields where a plausible-sounding output and a correct output are close enough to the same thing that a light spot-check is proportionate. Everything else needs the document, not the model’s judgement.

Adapt the rows to your own catalogue before you use this. A furniture brand needs a row for “assembly requirement.” A supplement brand needs a row for “dosage claim,” which behaves like a safety claim, not like a bullet description, and should route to whoever owns your labelling compliance, not to a merchandiser. A homeware brand selling into the EU needs a row for CE marking that a US-only brand does not. The columns stay fixed; the rows are yours to write.

What the model can generate directly, without a source document

Some fields are genuinely low-risk to let a model originate from pattern alone, because getting them wrong costs you a sale, not a return or a regulatory letter. Title rewrites that reorder existing information for search intent fall here. Bullet descriptions that restate a product’s known use case in different phrasing fall here. Meta descriptions, alt text drafted from an existing image caption, and internal search synonyms fall here too.

The test is not “does this sound right.” The test is: if this field is wrong, does the customer lose money, safety, or trust, or do they just click away. A weak headline loses a click. A wrong material loses a customer’s trust in every future claim your brand makes, and in a returns-heavy category, it loses the sale outright when the item comes back not matching its description.

Taxonomy placement sits in the middle. A model can draft a category assignment from an existing taxonomy and the product’s known attributes reasonably well, because it is working from a closed set of valid answers rather than inventing one. But taxonomy drives filtering, search facets and reporting rollups across the whole site, so a wrong placement is cheap per-SKU and expensive in aggregate: a hundred mis-categorised SKUs quietly break your best-seller report by category for a quarter before anyone notices why the numbers look strange. Treat taxonomy as draft-and-confirm, never auto-publish.

What a model must never invent, and why this is a consumer-protection problem

One rule governs everything else in this section: a model must never invent a material, certification, dimension, compliance claim or safety attribute. Not “should try to avoid.” Never. A language model generating catalogue copy has no way to distinguish a garment truly made of the material stated on its spec sheet from one that merely resembles, in a photo and a category, other garments described that way. It will produce a confident, specific material claim with exactly the same fluency whether that claim is true or a plausible-sounding guess, because fluency is what the model optimises for, not verification.

Materials, dimensions, weight, certifications, regulatory markings and safety claims are all facts about the physical world that exist in exactly one place: a supplier document, a lab report, a certificate, or a measurement someone actually took. A model has no access to that world. It has access to text that correlates with that world, which is a different thing, and the gap between the two is where a fabricated attribute enters a live product feed.

Call this what it is. A fabricated material claim on a product page is not a copywriting mistake to fix in the next content pass. It is a false statement about a physical product that a customer relies on to make a purchase decision, and in some categories, a safety decision. A “flame-resistant” claim invented because similar products in that category tend to carry it is not an edge case worth a footnote; it is the exact failure this rule exists to prevent, and it belongs in the same review category as a wrong allergen listing or a wrong age grading. Treat every one of these attribute classes as permanently in the “needs a human and a document” column of your review sheet, not as a temporary limitation of a model version you expect to improve past next quarter.

How the five-step review gate works before anything publishes

The five-column sheet tells you what to route where. This section is the mechanism: the actual sequence a batch of generated attributes should move through between draft and live feed.

Route every generated field through a confidence tag

At the point of generation, every field gets tagged directly-sourced, inferred, or unknown. Directly-sourced means the model was given the actual value and asked to phrase it. Inferred means the model produced a plausible value from pattern, category or similar SKUs, with no document behind it. Unknown means there was no basis at all, and the honest output is a blank field, not a guess. This tagging step is the difference between a review queue sorted by actual risk and a review queue that treats four thousand fields as equally worth a human’s time, which in practice means none of them get a real check.

Auto-approve only the fields marked safe-to-generate

Directly-sourced, low-consequence fields, the “Yes” rows from your template, can publish without a person in the loop. This is where the speed of AI catalog enrichment actually gets realised: a merchandiser is not reading four thousand title rewrites one at a time. But auto-approval should be a narrow gate defined by attribute class, never a blanket setting for “AI-generated content,” because that setting does not distinguish a rephrased title from an invented certification.

Route unsafe fields to a human with the source document attached

Every inferred or unknown field, and every field in a “No” row regardless of its tag, goes to a reviewer alongside the document it should be sourced from: the supplier spec sheet, the compliance certificate, the measurement record. A reviewer asked to approve a bare claim with no document attached will, under volume and deadline pressure, start approving on plausibility instead of evidence, which quietly recreates the exact problem the gate was built to stop. Attach the source or do not ask for the approval.

Spot-check a sample of the auto-approved batch

Even the “safe” lane needs an audit, because the safe-to-generate rule itself can be wrong, or a supplier feed can shift in a way that makes yesterday’s safe assumption today’s error. Pull a fixed percentage of the auto-approved fields on every run and check them against source data anyway. This step catches drift in the rule, not just errors in an individual field.

Log every override before the feed exports

Every correction, rejection or manual override gets logged with who made the decision and what evidence they used, before the feed goes out. When a wrong listing surfaces three weeks later, the question is never “did the AI get this wrong.” It is “who approved this, and on what basis,” and only a log answers that. Without one, every incident becomes an argument about the tool instead of a fixable process gap.

Where teams get the review gate wrong

The most common failure is not skipping the gate outright. It is building it, then letting it decay into a rubber stamp. A merchandiser given four hundred fields to approve by end of day will, on day one, check each one against the source document. By week three, under the same volume and the same deadline, they are scanning for anything that looks obviously wrong and clicking approve on the rest. The gate still exists on paper. It has stopped doing its job.

The fix is not a stricter policy memo. It is workload design: cap the number of fields any one reviewer checks per session at a level where checking the source document is genuinely faster than trusting the output, and rotate the auto-approve spot-check so no single person is the last line of defence indefinitely. If you do not know that cap for your own team, time a reviewer on a real batch before you set one; do not adopt a number from outside your own operation.

Routing every field to the same reviewer, regardless of what kind of fact it is, is a second common failure. A copy editor is well placed to judge whether a bullet description reads well and matches brand voice. A copy editor is not the right person to confirm a flame-resistance certificate, and asking them to sign off on it anyway either slows the whole queue down while they chase the right person, or worse, gets approved on the strength of plausible phrasing rather than genuine documentation. Split approval by who owns the source data, not by who is available.

Treating the review gate as a one-time build, rather than a rule set that needs revisiting, is a third, quieter failure. A new supplier with a different documentation format, a new product category with attribute classes your original template did not cover, or a new sales channel with its own compliance requirements all change what “safe to auto-approve” should mean. A gate built for last year’s catalogue and never revisited will keep waving through fields it was never actually designed to check.

What a fabricated attribute does once it reaches the feed

A wrong attribute does not stay contained to one product page. It travels. The same generated material claim that sits on your Shopify product page also flows into your Google Shopping feed, your marketplace listings, and any affiliate or comparison-shopping feed pulling from the same source. Google Shopping in particular has automated checks for attribute mismatches, and a pattern of them can lead to listing suspension across the account, not just the one SKU, which turns a single bad field into a channel-wide outage while someone works out which product caused it.

Downstream, a wrong dimension breaks shipping-cost calculation at checkout, which either eats margin on every order of that SKU or produces a customer-facing price that does not match what actually ships, both of which generate support tickets faster than the enrichment project saved merchandising time. A wrong material or care instruction increases returns in a category where returns already carry real cost: the item comes back, the box is opened, someone inspects it, and the reason code on the return says “not as described,” which is a data point that erodes trust in every future listing from that brand, not just the one SKU.

A wrong safety or compliance claim is the most serious version of the same problem, and the one most likely to have consequences outside the P&L: a marketplace can suspend the listing or the account, a regulator can act on a false safety marking, and a customer harmed by relying on a false claim has a dispute that is not really about ecommerce operations at all. None of these outcomes are hypothetical edge cases reserved for large enterprise catalogues. They are the direct, mechanical consequence of an attribute entering a feed without ever being checked against the document it should have come from, and they happen at a small catalogue exactly as they happen at a much larger one, just with fewer people watching for them at the smaller scale.

How to adapt the template for your own catalogue

The five-column review sheet is a starting structure, not a finished policy. Three things to change before you use it on a real import.

First, your rows will not match the sample rows exactly. Every category has its own attribute classes that carry real consequence: a food or supplement brand needs an allergen row and an ingredient-sourcing row that behave like safety claims, not like descriptions. A furniture or appliance brand needs an assembly-requirement row and a voltage or power-rating row. Go through your own catalogue’s product type before you start, and list every field that, if wrong, would generate a return, a compliance question, or a support ticket. Those are your “No” rows.

Second, your “who signs off” column needs real names or real roles, not a generic “merchandising team.” A review gate with no named owner per attribute class defaults to the busiest person in the queue skimming everything, which recreates the same rubber-stamp failure: a gate that exists on paper but no longer functions. Assign compliance-adjacent attributes to whoever actually owns compliance in your organisation, even if that means routing fewer fields faster and more fields slower.

Third, revisit the sheet on a schedule, not only when something goes wrong. A quarterly review of the attribute classes, tied to any new supplier, category or sales channel added in that period, keeps the “Yes” and “No” rows honest. What breaks if you skip this step is not immediate: it is a slow drift where the gate still exists, still has rows, and no longer reflects what your catalogue actually needs checked, until an incident forces a rebuild under worse conditions than a scheduled review would have.

Who this template is not for

If your catalogue is small enough that one person enters every new SKU by hand and already checks every material and dimension against a supplier sheet as a matter of course, this template adds process overhead without adding safety; keep doing what you do. If you are below the roughly $3M revenue range this site is written for, or running on a platform without the catalogue and feed tooling to support automated review routing, the honest answer is that a review gate built for volume you do not yet have is a cost with no matching benefit. Build it when the SKU count makes manual, document-by-document checking genuinely too slow to keep up with, not before.

The template also does not fix the underlying data-quality work it depends on. If your supplier documentation is inconsistent, missing, or spread across formats no system can reliably parse, no review gate fixes that; it only makes the gap visible faster, at the point where a reviewer has no document to check the generated field against. That gap is a sourcing and data-governance problem, and it needs solving on its own terms before AI catalog enrichment can run safely at any volume.

Getting AI catalog enrichment right at scale is a catalogue and feeds problem before it is a content problem: the review gate, the source-of-truth mapping and the export pipeline all have to work together, or a fabricated attribute reaches Google Shopping the same day it reaches your storefront. That coordination across catalogue, feed and channel is what Pointerflow’s catalogue and feed automation service is built to handle.