Why Category Constraints Break Generic AI

Generic AI writes fluent product data. Fluent and correct are not the same thing. The gap between them is where product catalogs fail, and it is a constraint problem, not a content problem.

The failure most teams misdiagnose

Ask a general-purpose model to fill in a product record and it will do it. The output will read well. The attributes will be populated, the description will scan cleanly, and the units will look right. Then a marketplace rejects the listing, or worse, accepts it and the data is quietly wrong on the shelf.

The instinct at that point is to treat this as a content quality problem. Better prompts. A better model. More review. That instinct is wrong, and it is expensive, because it aims effort at the part of the system that was never broken. The model is not bad at writing. It is blind to the rules of the category it is writing into.

What a category constraint actually is

A category constraint is a rule that is true inside one branch of a taxonomy and false outside it.

Some are unit conventions. A cable category allows length in feet or meters. A fastener category allows millimeters only. Some are vocabulary. A furniture category may accept “walnut” as a material value and reject “brown wood.” Some are structural. A category defines which attributes may vary across a product family. A shirt varies by size and color. A drill bit varies by diameter and shank type.

The canonical example we use internally is color normalization. A rule that collapses shades into a controlled set of color names is correct for office furniture. Apply the same rule to writing instruments and it becomes a defect, because in that category the shade is the product.

Now multiply. A working catalog crosses hundreds of categories. Each one carries its own attribute requirements, its own allowed values, its own unit conventions, and its own identifier logic. Our constraint engine covers more than 400 of them. No single set of rules is correct across all of them, and no rule from one may leak into another.

Three ways generic AI breaks on this

1. It optimizes for plausibility, not conformity. A model produces the most likely value given everything it has seen. Marketplaces do not accept likely values. They accept allowed values. Those two sets overlap often enough to be dangerous and diverge often enough to be costly. A plausible material name that is not in the category vocabulary fails at the door, and it fails silently until the door is reached.

2. Rules leak across categories. A model carries one context across a run. Patterns learned from the records it processed a moment ago inform the records it processes next. That is useful behavior almost everywhere else. In a multi-category catalog it is contamination. The unit convention from the last category bleeds forward. So does the attribute name from the category before it. None of it is flagged.

3. It cannot tell you when it is wrong. This is the failure that matters most. A generative model returns a correct value and an incorrect value with the same confidence and the same fluency. There is no internal signal that separates them. Reviewing the output does not help either, because the errors that survive review are precisely the ones that look right. A wrong value in a category you do not know well is invisible to everyone in the chain.

Why a better model does not fix it

The natural response is to reach for scale. A larger model, a longer prompt, a retrieval layer holding the category rules. Each of these helps at the margin. None of them changes the shape of the problem.

The constraint space is the reason. Hundreds of categories, each with its own vocabulary, unit conventions, variant logic, and identifier format, is not a context problem a bigger window solves. It is a governance problem. Rules have to be encoded, versioned, and enforced independently, so that a change to one category cannot alter the behavior of another.

And even a model that held every rule perfectly would still lack the one thing the job requires: a mechanism to fail. Generation has no concept of rejection. It always returns something. A system that always returns something cannot be the system that decides what ships.

The architecture that does work

The answer is separation, and it is an architectural decision rather than a tuning decision.

AI generates. Generation is the right tool for the enormous space of possible product content, and no rule-based system can cover that space. Deterministic logic validates. Validation is a different discipline with a different success condition, and it must not run inside the same pass that produced the value. That separation is one of the requirements product data enrichment has to meet to be worth doing.

Validation itself works on two levels. Deterministic checks settle everything a rule can decide: format, check digits, uniqueness, required fields, unit conventions, and category vocabulary. A value either passes or it does not, and the result is reproducible. Semantic checks handle what rules cannot. They read across the whole record and catch claims that are each well formed but do not agree with one another. A material stated one way in the title and another way in the attributes is not a format error. Only a check that reads for meaning finds it.

Then the part that makes the rest matter: a hard failure gate. A record that fails is flagged and documented with its reason. It is not silently dropped and it is not silently passed. That is exception transparency, and it belongs in any honest measure of product data quality. Accuracy over coverage is the tradeoff we take every time. Ten thousand records you can stand behind, with the exceptions named, beats thirteen thousand with errors buried inside.

Why this gets more expensive as agents read the catalog

For a long time the reader of a product record was a person who could infer around a gap. That is changing. AI agents do not browse and they do not infer generously. They compare on structured values and act on what they are given.

An unvalidated attribute used to be a soft gap in a page a human skimmed. It is now a wrong answer a machine reads, trusts, and acts on. The cost of a constraint violation goes up as the reader becomes literal, and the reader is becoming literal quickly.

How atronous is built

Atronous is built around this separation. AI generates product data across the full space where generation is strong. A constraint layer encoding category-specific rules across more than 400 product categories validates every record, with each category’s vocabulary enforced independently. Every record passes through up to seven validation checks before delivery. Records that fail are returned flagged and documented, with the reason attached. Then atronous activates the verified data into the systems that carry it forward.

A rule governing office furniture cannot contaminate writing instruments. That is not a promise about model quality. It is a property of the architecture.

See it against your own categories

The argument is easy to make in the abstract. It is more useful to see it run on your records. Send up to 50 SKUs out of your PIM or ERP, exactly as they live in your system. Within five business days the atronous Data Quality Assessment returns them generated and validated, with the taxonomy and schema recommendations behind the work. A specialist walks through what we found and why each category behaved the way it did.

Request your Data Quality Assessment.

Intelligence in every attribute.