I Almost Let Our Product Data Tool Fix Too Much
The more we automated product-data repair, the more obvious one problem became: knowing something is wrong is not the same as knowing the right answer.
When I first started thinking about product-data repair, the idea seemed pretty simple.
Find the bad fields.
Correct them.
Export a cleaner file.
Done.
That is probably how I would have described the product a few months ago.
The problem appeared when I started thinking about what should happen after the system finds a conflict.
Let’s say a catalog says a product costs $39, but the live page says $49.
Easy.
Change $39 to $49.
Except… maybe not.
What if the feed contains a sale price that hasn’t gone live yet?
What if the page is showing the wrong variant?
What if the website failed to update and the feed is actually the correct source?
The system can be completely certain that something does not match while having no idea which side is actually right.
That distinction ended up changing the way I designed Mingche’s repair flow.
At one point, the obvious direction was to automate as much as possible.
If the system detects something wrong, fix it.
That sounds good in a product demo.
It also sounds good in marketing:
automatic audit
automatic repair
automatic output
Very clean.
But I kept coming back to the same uncomfortable scenario.
Imagine a merchant uploads a catalog with a missing GTIN.
The system knows the field is empty.
Should it fill it?
No.
There is no safe value to invent.
The same thing happens with material, dimensions, variant information and sometimes even price.
The system may know:
“This record looks wrong.”
It does not necessarily know:
“This is the correct replacement.”
That is why Mingche’s workflow ended up keeping a review step instead of letting the agent silently change everything and publish the result.
It makes the workflow a little less magical.
I think it makes it much safer.
A missing field is annoying.
A wrong field that looks legitimate is worse.
That sounds obvious when you say it out loud, but automation makes it surprisingly easy to forget.
There is a temptation to optimize for a cleaner spreadsheet.
Fewer blanks.
Fewer warnings.
Higher completeness.
Everything green.
But a catalog can look beautifully complete and still contain bad information.
If the material is unknown, writing “cotton” because it seems plausible does not improve the product.
If the GTIN cannot be verified, generating something that looks like a GTIN is not a repair.
If two variants disagree, choosing whichever one appears first is not intelligence.
It is guessing.
And once that guessed value goes back into the product feed, it stops looking like a guess.
It becomes data.
That is the dangerous part.
So I ended up thinking about repair in three buckets.
Not because three buckets make a nice framework for a blog post.
They just reflect what the system actually has to decide.
Get Rowmint | Product Data Lab’s stories in your inbox
Join Medium for free to get updates from this writer.
There are changes we can support with evidence.
There are conflicts that need someone to look at them.
And there are things we simply do not know.
The last category is the one I care about most.
I would rather have the system say:
“I don’t know.”
than quietly manufacture an answer.
That is also one of the reasons the paid audit workflow in Mingche does not simply go:
payment → agent → publish
There is still a review before the result reaches the customer.
The agent can do a lot of the repetitive work.
It can compare fields.
It can identify mismatches.
It can organize the findings.
It can generate a proposed repair.
But there is a point where automation stops being the useful part.
Someone still needs to ask:
Do we actually have enough evidence to make this change?
I used to think the best product would be the one that automated the largest percentage of the workflow.
I don’t think that anymore.
Now I think a better system is one that knows which parts should not be automated.
That sounds less impressive than “fully autonomous.”
But product data is full of facts.
Price.
Stock.
GTIN.
Size.
Material.
Brand.
Variant relationships.
These are not creative fields.
A wrong answer is not just ugly copy.
It can become a wrong product record.
This has also changed how I think about AI in ecommerce more generally.
AI is extremely good at producing plausible answers.
That is one of its strengths.
It is also exactly why factual commerce data needs a different standard.
“Plausible” is useful when you are brainstorming a headline.
It is not enough when you are deciding which identifier belongs to a physical product.
There are places where generation is valuable.
There are places where verification matters more.
Product-data repair sits much closer to the second category.
The funny thing is that this has made the product less ambitious in one way and more useful in another.
Less ambitious because I no longer want it to pretend it can solve every field automatically.
More useful because when it does make a change, I want that change to be explainable.
What was the old value?
What is the new value?
Why did it change?
What evidence supports it?
And what did the system intentionally leave alone?
That last question matters.
Sometimes “no change” is the correct result.
I’m still building this workflow, and I’m sure parts of it will change.
But one rule probably won’t:
Finding a problem is not permission to invent the fix.
For product data, I’d rather ship a report with a few honest unknowns than a perfect-looking file full of confident guesses.
That is slower.
It is also the version I would trust with my own catalog.
