Source hierarchy must be enforced, not recommended
A textbook case: a retailer's commercial document was mistaken for a manufacturer data sheet. The agent read incorrect material, “corrected” a value that was already right, then propagated it to every variant of the model. The audit measured the gap: with this type of misclassified source, the error rate can reach 100%, compared with roughly one value in five requiring correction in uncontrolled official sources. The lesson is not “write a better prompt”. A prompt rule can be bypassed; a mechanical safeguard cannot. The source hierarchy — manufacturer data takes precedence and a lower-ranked source cannot overwrite a higher-ranked value — must be enforced by the system.
Propagation amplifies everything — right or wrong
Processing at model level and propagating values to variants reduces costs — the main advantage of parent/variant grouping — but it also amplifies errors. One false value on the reference product mechanically becomes fifteen errors, one per variant. Quality control must therefore prioritise the “champion” products whose values propagate, and treat any divergence between variants of the same model as a free warning signal.
Certifications must never be inferred from a related term
The example that established this rule: all S1 and higher safety shoes are antistatic by design, but they are not all ESD-certified — ESD is a separate and stricter certification. An agent had marked hundreds of products as “ESD” based solely on the word “antistatic” in their descriptions. Since then, a regulatory field — standard, certification or compliance — is never inferred from a related term or indirect reasoning. Either a source attests it, or the field remains empty.
The quality checker can degrade the data
Poorly scoped automated quality control causes damage with complete confidence. In one real case, a checker “corrected” enriched names by reverting them to raw catalogue codes because it treated every difference from existing data as an error — even though adding context to a name was precisely the expected outcome. Three rules followed: improvement is not an anomaly; product references are untouchable; and only factual technical errors justify a correction. One architectural principle followed too: no checker should redo the work afterwards. Every value is checked against its source within the same session and corrected immediately.
Completeness is not a measure of quality
It is a favourite dashboard metric and the most misleading. Some technical categories have more than a hundred possible attributes: a perfectly enriched product may fill only a fraction of them, while 50% average completeness may be excellent — or disastrous — depending on the categories. Worse, maximising completeness encourages invention. Better indicators lie elsewhere: the proportion of values linked to a source, the correction rate during review and consistency across variants of the same model.
What works: three layers of control
| Layer | What it covers | What it catches |
|---|---|---|
| Mechanical checks | 100% of products — deterministic, without AI: a safety net that never tires. | Out-of-schema values, invalid formats and numerical inconsistencies. |
| Value ↔ source comparison | Every written value, with explicit verdicts: verified, partial, not found or not verifiable. | Invented values — “not found” is the reliable signal; “verified” on a short value only means that nothing looks abnormal. |
| Sampling + human review | A second look at a sample against manufacturer documents, plus a review queue. | Edge cases: product not found or contradiction between sources — AI proposes, human oversight decides. |
Harmonisation: the silent workstream
Making data reliable also means reducing noise. The same values written ten different ways — synonyms, spelling variants and borrowed terms — make website filters unusable even when every value is technically correct. Reducing a field with thirty-four written variants to a canonical list is not cosmetic: it is what makes the data usable by a search engine, a product configurator or a customer.
Related topics: product data enrichment · categorisation · parent/variant