Catching what a data teamcan't see.

A product record can contradict itself. The title can say one brand while the brand field says another; the RAM in the title can disagree with the RAM in the specification. These errors are invisible to a human skim-reading a product page — but not to Google's feed validator, and increasingly not to the AI shopping agents that now sit between retailers and their customers. We built a test harness to prove CatalogueScore's verification engine catches them.

What we set out to test

CatalogueScore verifies whether retail product data is correct, consistent, complete, and valid — without modifying, enriching, or retaining any customer data. The method uses an OWL ontology engine to find self-referential errors within a feed: internal contradictions, formatting violations, and missing mandatory fields that exist independently of any external reference.

Before running that engine against a real retailer's feed, we needed to answer a more basic question: does it reliably catch the errors it is designed to catch? To measure that properly, you need a dataset where you already know every error — so you can check what the engine finds against ground truth. That is exactly what this exercise does.

The method

We constructed a controlled test dataset of 220 laptop product records modelled on Google Merchant Center feed specifications — the standard format UK retailers use to list products on Google Shopping. The records use realistic field structures: product titles, brand fields, pricing, GTINs, condition flags, category classifications, and specifications including RAM, storage, screen size, and operating system.

Into that dataset we deliberately seeded 61 errors across ten categories, at known locations. Roughly three-quarters of the records were left clean. We then ran CatalogueScore's engine across the whole feed with no knowledge of where the errors were, and compared what it found against the manifest of what we had planted.

The engine applies ten rule categories, each derived from Google Merchant Center requirements and internal data consistency principles:

• E1 Brand field must match the brand named in the product title
• E1b Brand field must use consistent, canonical formatting
• E2 RAM value in the title must match the spec field
• E3 Storage value in the title must match the spec field
• E4 Price must conform to GMC format: 0.00 GBP
• E5 GTIN must be present and valid
• E7 GTIN must be unique across the feed
• E8 Condition must use a permitted GMC value: new, refurbished, or used
• E9 Screen size in the title must match the spec field
• E10 Operating system implied by the title must match the spec field

Critically, none of these rules requires an external reference dataset. The engine finds errors that exist purely within the feed itself — the kind a retailer's own data team may never notice until a product is disapproved by Google or skipped by an AI agent.

---

The result

The engine found 57 of the 61 seeded errors, with zero false positives. Against Google Merchant Center's compliance rules, the test feed scored 75.5 out of 100.

Error breakdown

Error type	Severity	Found
Brand field contradicts title	HIGH	8
Price format violation	HIGH	8
Condition field invalid value	HIGH	7
Brand formatting inconsistency	MEDIUM	7
RAM value contradicts spec	HIGH	6
Storage value contradicts spec	HIGH	5
OS contradicts spec field	HIGH	5
Missing GTIN	HIGH	5
Screen size contradicts spec	MEDIUM	4
Wrong product category	HIGH	4
Duplicate GTIN across records	HIGH	2

Actual findings from the run

Every example below is a verbatim finding from the engine's output — not a reconstruction.

---

How well did it perform?

Because every seeded error was known in advance, we can measure the engine's accuracy exactly.

Every finding the engine raised was a genuine seeded error — nothing was falsely flagged. The four it missed were storage contradictions where neither the title nor the spec carried an explicit SSD or HDD label; the engine correctly declined to guess storage type from ambiguous data. That restraint is the point. A verification service that guesses is worse than useless — it erodes the trust that makes verification worth paying for.

---

What this proves — and what it doesn't

This is a controlled test on a synthetic dataset. It demonstrates that the engine reliably detects the ten categories of internal contradiction it is designed to catch, with high recall and no false positives. It does not, and cannot, tell you how many errors a specific retailer's real feed contains — that requires running the engine against that retailer's actual data. What it establishes is that when the errors are there, the engine finds them, and when they are not, it stays quiet.

That distinction matters, and it is the discipline CatalogueScore is built on: we report what we can verify, and we are explicit about what we cannot.

— McKinsey, The Rise of the Agentic Shopper: ASOS's AI Investment, 2026

The reason this matters now is timing. McKinsey models agentic commerce at $3–5 trillion globally by 2030. As AI agents increasingly mediate product discovery and comparison, the errors this engine catches stop being minor data-hygiene issues and become the difference between a product an agent can act on and one it silently skips. A record whose title and specification disagree is a record an agent cannot trust — and an agent that cannot trust a record moves on to one it can.