On 15 October 2026, Lightspeed announced an opt-in beta in which an agent prepares updates to product information, shows a preview and waits for the retailer’s approval before anything is written. That is the right pattern. An agent proposes, a person decides, and nothing reaches the catalog on the agent’s say-so alone.
But I think the industry is being too polite about the harder half of that pattern. An agent can only propose a sensible change if it knows which oddities in the data are defects and which are decisions somebody made on purpose. In a recent discovery session with a B2B manufacturer, we watched the customer answer that question for every anomaly in a sample, in seconds. A validator could not have answered it at all.
The sample
We had received a sample of about a thousand part numbers across roughly a dozen product series. Our analysis flagged a set of inconsistencies, as any decent validation does. In the session, we put them in front of the person who owns their product data. For each one, the explanation came immediately. None of them needed a second meeting.
What matters is that the explanations were not the same kind of explanation.
Four anomalies, four different answers
| What the validator saw | What it turned out to be | The right response |
|---|---|---|
| The same EAN on several part numbers | Special-version part numbers that reuse the base product’s EAN and add a short suffix. Intentional. | Keep both records. Model the relationship and choose the unique identifier on purpose. |
| Voltage written in several different ways | A habit with no enforced format, from some months earlier. The customer’s R&D team was being trained on a locked Excel template to stop it at the source. | Normalize with a rule now, and fix the cause upstream. |
| Length, width and thickness in one cell | A structural question. The customer wants three separate fields, and splitting them reliably is harder than it looks. | Propose a split, show a preview, let a person confirm. |
| The text “Download PDF” where a link should be | An export defect. The customer noted the fix on their side. | Do not import it. Fix it at the source. |
One anomaly was a business rule. One was drift. One was a data-structure decision. One was an actual defect. Four flags that look similar in a validation report called for four different actions, and only one of the four is what most people mean by “an error”.
We have not measured what share of anomalies in supplier files are rules and what share are defects, and four examples from one sample do not give a rate. What they show is that the classes exist, and that a system treating all flags as errors will mishandle at least some of them.
Why automatic correction is the wrong default
Consider the first row. A rule-based cleaner sees duplicate EANs and does what it was built for: it deduplicates. The special versions merge into the base product, or one of them is dropped. The catalog now looks cleaner, the validation report goes green, and a business rule that the customer relied on has been erased. Nobody will notice for weeks, and the person who finds out is the one handling an order for the special version that no longer exists as a record.
AI doesn’t fix bad data. It amplifies it. An automated fixer applied to a rule is a very efficient way to amplify a mistake across a thousand records. The danger lies in the confident fix, not in the detection.
Propose, preview, approve
The workable design has three parts, and each is visible in the table above.
- Classify before acting. For each flagged anomaly, the system proposes a class (defect, drift, structure, possible rule) along with its reasoning, and does not propose a fix as though every flag were a defect.
- Preview before write. A person sees what would change and in how many records before anything is written. In the dimensions example, a proposed split is shown against real values so that the reviewer can see where parsing fails.
- Decide once, apply many times. Review does not scale if every record needs a click. In a separate pilot with a different customer, a team of builders and reviewers took about 550 decisions, most of them in bulk. For one supplier’s file, 184 of 200 decisions were resolved in a single action. A rule confirmed once applies to every record that matches it.
That is what “AI proposes, you decide” means in practice. It is a design for the review step, and it matters more than the extraction step.
What this costs, and what it saves
I do not have a measured figure for the cost of a wrongly applied auto-fix, so I will not invent one. The argument is about asymmetry, and you can test it against your own incident history.
Review costs minutes and happens at a moment of your choosing, before the write. A silent wrong fix costs more because it surfaces downstream: a marketplace rejects a listing, a customer disputes an invoice, or an agent selling from your catalog quotes the wrong variant. By then the damage is spread over records, and the original cause is hard to find. If your onboarding process cannot show who confirmed a given change, the cost of every such incident includes the time spent working that out.
This is also where audit trails start to matter commercially. Sooner or later, someone will ask who approved what an AI agent changed. A system that records the proposal, the reviewer’s decision and the source file gives you the answer without a forensic exercise.
Four questions to ask any onboarding tool
- Does it distinguish a defect from a possible business rule, or does it treat every flag the same way?
- Can I see a preview of a proposed change against real values before it is written?
- Can I confirm a decision once and have it apply to every matching record?
- Does it record the source file, the proposal and who approved it?
If the answer to the first question is no, the tool will eventually delete something you wanted to keep. If the answer to the second is no, you will find out after it has.
The closing question
Your suppliers’ files are full of choices that look like errors from the outside. Some of them encode how your business or theirs actually works. The cheapest way to find out which ones is to ask the person who knows, at the moment it matters, with a preview in front of them.
Are you automating work, or automating rework?
To see how this works on your own supplier files, read how to test an onboarding tool on your data, or book a demo.
Related reading from the openProd Academy:
