The Most Dangerous Product Data Error Is the One That Looks Reasonable
A broken value is easy to catch. A believable wrong value can pass validation, survive review, and quietly become the product everyone trusts.
Some product-data errors are almost comforting.
A price field says:
banana
Fine.
Something is obviously broken.
A GTIN has the wrong number of digits.
Easy to flag.
Availability contains a value the system does not recognize.
Again, obvious.
Those errors are annoying, but they have one useful quality:
they look wrong.
I’m increasingly more interested in the other kind.
The value that looks completely normal.
And happens to be false.
Take a price.
The feed says:
$129
The field is valid.
The currency is valid.
The formatting is valid.
The number is plausible.
Nothing about $129 looks suspicious.
Except the actual product costs:
$109
There may be no red warning until another system compares the two.
And even then, someone still has to decide which value is correct.
That is a much harder problem than rejecting “banana.”
The same thing happens with identifiers.
Imagine a GTIN exists.
Correct length.
Only numbers.
Passes basic validation.
A dashboard happily shows a green check.
But the GTIN belongs to another variant.
Now the field is technically better than blank.
It is also materially worse.
A missing identifier says:
We don’t know.
A plausible wrong identifier says:
We know exactly what this is.
That confidence is what makes it dangerous.
I think software naturally prefers the second situation.
Machines like complete records.
Dashboards like green states.
People like seeing:
100% complete
instead of:
94% complete.
There is psychological pressure to make uncertainty disappear.
And AI makes that easier than ever.
If a field is missing, a model can often suggest something that looks right.
Material?
Cotton.
Category?
Running shoes.
Color?
Charcoal.
Product type?
Men’s athletic footwear.
Every answer may sound perfectly reasonable.
The problem is that product data is full of questions where reasonable is not the same as true.
This is one reason the “Needs Review” state in Mingche matters to me.
A system can detect:
Something here does not line up.
What I do not want is for that detection to automatically create a replacement merely because the interface expects one.
Sometimes the correct output should be:
I found the problem. I cannot safely determine the answer.
That looks less impressive in a demo.
I think it is a better product.
There is a subtle difference between two kinds of automation.
One tries to reduce the amount of uncertainty the user sees.
The other tries to make uncertainty easier to see.
I’m starting to prefer the second one.
Because hiding uncertainty does not remove it.
It just turns it into data that looks more trustworthy than it really is.
Consider a variant example.
A product feed says:
Black / Medium
The URL opens:
Black / Large
Suppose the system decides the feed must be wrong and changes Medium to Large.
Get Rowmint | Product Data Lab’s stories in your inbox
Join Medium for free to get updates from this writer.
That might be correct.
Or the URL might be wrong.
Or the default variant might be wrong.
Or the link might have lost a parameter somewhere upstream.
There are several explanations.
The visible mismatch is evidence that something needs attention.
It is not necessarily evidence of which side deserves to change.
That distinction keeps showing up.
And it becomes more important once repaired data leaves the tool.
A wrong suggestion inside a dashboard is still contained.
A wrong suggestion that gets approved and exported becomes:
a feed value,
then perhaps a Merchant Center value,
then perhaps marketplace data,
then something another system consumes.
At that point the guess has acquired history.
Later, somebody may compare another system against it and assume the exported value is authoritative.
A plausible mistake can slowly become the “source of truth.”
That is the part I find unsettling.
This is probably why provenance matters more to me now than when I started thinking about product-data tooling.
Not only:
What is the value?
But:
Where did this value come from?
Was it entered by the merchant?
Read from the live page?
Taken from structured data?
Copied from an older feed?
Inferred by a model?
Confirmed during review?
Those are not equivalent sources.
Two identical-looking values can deserve very different levels of trust depending on where they came from.
There is a temptation to solve this with confidence scores.
Maybe:
98% confidence
looks reassuring.
But I’m not sure a percentage solves the underlying problem.
If the only available evidence is weak, being highly confident does not make the evidence stronger.
For some product facts, I would rather see:
Merchant confirmation required
than:
AI confidence: 94%
The first tells me what actually needs to happen.
The second mostly tells me how certain the system feels.
Those are different things.
I’m also starting to think that this is one of the places where AI-commerce tooling can go wrong in a very ordinary way.
Not because the AI does something dramatic.
Because it produces a clean, believable answer.
The user looks at it for two seconds.
Nothing seems strange.
Approve.
That is probably more realistic than the spectacular AI failures people usually talk about.
A wrong answer that looks ridiculous gets caught.
A wrong answer that looks boring might survive.
That changes what I think a good product-data interface should emphasize.
Not just:
Error detected
and:
Suggested fix
but also:
Evidence
and:
Why this suggestion exists
and sometimes:
We don’t have enough information yet
The interface should make it easy to challenge the machine.
Not only easy to approve it.
This is a little inconvenient from a product-design perspective.
“Approve all fixes” is satisfying.
“17 fixes ready, 6 require review, 3 cannot be resolved” is messier.
But the catalog was already messy.
The software did not create that uncertainty.
Pretending it disappeared would just make the interface cleaner than reality.
I don’t think that is a good trade.
The more I work around this problem, the less I think the goal is to eliminate blanks.
The goal is to eliminate false certainty.
A blank can be researched.
A warning can be reviewed.
An obviously broken value gets attention.
The dangerous value is the one nobody questions because it looks exactly like the truth.
