Data as a prerequisite

The audit is done and you have a rollout queue. Before you launch the first automation, do one thing: export the catalog to a file and actually open it. The typical view looks like this: an ERP export, six thousand rows, a "color" column full of "black", "Black" and "BLK". Size written as "M" in one row and "38" in another. The parent EAN copied onto every variant. Nobody planned it. That is simply what a catalog looks like after five years of several people maintaining it across three systems.

The problem is that almost every use of AI in a store reads exactly that file: descriptions, translations, feeds, answers to customer questions about specs. Hence the uncomfortable premise of this chapter: AI will not fix messy data, it will multiply the mess. There is good news too. You do not need a perfect catalog, because no such thing exists. You need order in the fields your first workflow will touch.

An automation repeats the error in every row at once

When a person writes descriptions, the data quietly corrects itself along the way. An editor looks at the photo, sees "black" in the column while the product is graphite, and fixes it. An automation will not. It executes exactly what it was given. Across three hundred products. Just as patiently and just as wrongly.

That is the real difference: manual work produces single, random mistakes, automation produces systematic ones. A systematic error has one advantage, since a single rule change fixes it. And one serious drawback: until it is fixed, every customer sees it in every channel.

A quality ceiling no tool will break through

The second thing that is easy to miss: data sets the quality ceiling of every workflow. If the catalog holds no capacity, no material and no dimensions, a description generated from it will be flowery and empty, because there is nothing concrete to build from.

The worse version: the model fills the gap with something that sounds plausible. You end up with a spec nobody verified, in a channel that is accountable for it. The cost of that error does not stop at a fix in the file. It shows up in returns, complaints and rejected listings.

Six checks before you launch anything

You run this review once, on an export from the real source. You do not need the whole catalog: a few dozen random items plus a handful of deliberately hard ones (variants, bundles, products with several units) is enough. You are answering one question: are the errors isolated or systematic.

Run the review on the export, not in the admin. The admin shows data the way a human wants to see it. A workflow reads the file.

Do not do this by hand, because hunting duplicates and inconsistent units is repetitive work in its own right, which makes it a good task for a tool. The technical side of such a review, with the rule of working on a copy and reviewing the diff before saving, we covered step by step in the piece on cleaning a catalog CSV. What stays here is the decision layer: what has to be true about your data before an automation has anything to work with.

"Written for humans" is not the same as "readable by machines"

This distinction accounts for half of the failed rollouts. The sentence "water resistant, it will survive a shower just fine" is clear to a customer and useless to a system. Each machine consumer wants something different:

• A sales channel: an attribute with a fixed name and a value from a closed list.
• A store filter: a number.
• A model answering a customer question: a field where that value simply sits.

Hence the rule: if a parameter is meant for a filter, a feed, a comparison engine or an answer, it has to live in its own field, with a predictable name and a value from a controlled list, not in the middle of a sentence.

Two tests: data or text

A model can extract parameters from prose, and sometimes that is a sensible shortcut, but let us call it what it is: high-accuracy guessing. It is fit for rescuing legacy data, not for being the source of truth.

Two quick tests show which side your catalog is on:

• The filtering test: can the data be sorted and filtered without reading any descriptions?
• The two-people test: would two different people enter exactly the same value into that field?

A single "no" means the field is text rather than data. A workflow built on it will break in places you did not anticipate.

One source of truth: every field has an owner

In practice almost nobody runs a single system. Prices and stock live in the ERP, descriptions in the store or a PIM, the marketplace keeps its own attributes, and a marketing spreadsheet sits alongside. One source of truth does not mean a grand migration into one tool, because such a migration is often more expensive than the problem it solves.

It means something simpler: for each field you name one system that owns it, and the others read that field instead of overwriting it. Conflicts are settled by the field owner, not by whichever write happened last.

Without this, a workflow runs correctly and is still useless: the automation improves descriptions in the store, the nightly ERP sync overwrites them with the old version, and you find out two weeks later. Writing down field owners is one afternoon: take the fields your first workflow will touch and note the source system and the direction of flow for each.

The knowledge hub: do the same with company knowledge

The catalog is only half of the source of truth. The other half is knowledge that in most companies lives in no system at all: brand voice, discount rules, the returns procedure, the reasons behind decisions ("we do not ship cash on delivery because…"), the most common customer questions and the answers you have worked out for them.

That knowledge lives in heads, on Slack and in old emails. Every new employee spends months collecting it. And every AI workflow starts from zero without it.

Four files to start with

The solution sounds less serious than it works: a folder of plain text files that AI agents read before every task. You do not need a platform, four files are enough to start:

• Brand voice: with an example of a good and a bad description.
• Pricing: the rules for prices and discounts.
• Returns and complaints.
• Decisions: what was decided and why.

The magic is in compounding: when you correct a draft and add the reason to the right file, that correction stays in the system for good. A human teaches once, every future workflow benefits.

After six months the gap between a company that does this and one that explains everything from scratch each time is hard to close. We work this way ourselves on client projects: our own knowledge hub about the company and its clients is read by agents on every engagement, and it is that hub, not clever prompts, that makes the biggest difference in quality.

Two boundaries from day one

Secrets (passwords, API keys, access credentials) and customer personal data do not go into the hub, because these files will be read by tools and people, and rotating access to them has to stay simple. What goes in is knowledge about how the company works and why. How to build such a hub step by step, from the first file to a structure the whole team maintains, we show in chapter 7.

Cleaning in three passes

The order has a financial consequence, because any pass done at the wrong stage has to be repeated. Run them in sequence and check a sample after each one, rather than firing everything at once.

Pass one: required fields and identifiers

You start with what a product cannot exist in a channel without, and with the keys that connect your systems. Gaps in required fields block publishing, and a duplicated identifier derails everything downstream that tries to join data from two sources. One hard boundary: missing identifiers are not generated. A valid GTIN comes from GS1 or the manufacturer. The tool should flag the gap reliably, not invent a value.

Pass two: consistency

Now you unify variants, units, colors and categories, and resolve duplicates. The output is not just a cleaner file but a set of value dictionaries: the list of allowed colors, the unit format, the mapping of categories onto the channel taxonomy. Those dictionaries are the first residents of your knowledge hub and the input for everything you launch in the next chapter.

Pass three: enrichment

Filling attributes, writing descriptions, translating and adding data for search all come last, on a catalog that is already in order. Reversing the order is the most expensive mistake of this stage: you enrich records that turn out to be duplicates, or write copy for variants that will have to be split differently. You pay twice for the same work, and the second time is usually pricier.

The exit criterion is practical, not perfect. Three things are enough:

• A clean sample: a few dozen random products with no gaps in required fields, unique identifiers, consistent variants and one unit format.
• Field owners written down: you know which system owns which fields.
• A knowledge hub folder: created, even if it holds just two files.

That is enough to launch your first workflow. Which is what the next chapter covers.