Why ProductKnowledgeGraph Pilots Start With Measurement, Not Integration

There is an easy way to make an AI product-data project look successful. Change the data. Wait. Ask AI some questions. Find a better answer. Declare improvement.

We don't think that is sufficient evidence.

ProductKnowledgeGraph pilots therefore begin somewhere less exciting: before anything is changed.

First, establish what AI actually does today

Before publishing a new Product Truth layer, we capture a baseline. For a defined product set, we ask repeatable questions about areas such as:

• exact product and model identity;
• specifications;
• manufacturer information;
• regulatory relationships;
• authoritative source selection;
• model and revision distinctions;
• buyer-facing product questions.

The purpose isn't to produce an arbitrary "AI visibility score." It is to create a before-state that can be tested again.

Different events prove different things

This distinction matters enormously.

Publishing information does not prove AI saw it. A crawler visiting it does not prove the information was retrieved for an answer. Retrieval does not prove it was cited. Citation does not prove the answer changed. And an answer changing does not automatically mean it became more accurate.

These are separate events:

Published → Accessible → Crawled → Retrieved → Cited → Fact Matched → Answer Influenced

Collapsing them into one metric creates attractive dashboards. It does not create evidence.

Then we connect Product Truth

Once the baseline exists, the product-information layer can be made explicit. Depending on the product, that can include relationships such as:

Product → Model
Product → Variant
Product → Component
Product → Regulatory Record
Product → Evidence
Product → Offer

The goal isn't to replace the systems already managing these records. PIM, ERP, CMS, ecommerce and regulatory systems continue doing their jobs. The goal is to make the relationships AI needs explicit and measurable.

Then we ask the same questions again

This is the important part. Same product. Same question. Same AI provider where possible. Same evaluation criteria.

Now there is something meaningful to compare.

Some answers may improve. Some may remain unchanged. Some systems may behave differently from others. A source may become accessible without influencing an answer.

All of those are valid results.

"No measurable change" is a result

A pilot should be able to fail. Otherwise it isn't a pilot.

If publishing explicit Product Truth produces no measurable change, the result should say: no measurable change.

That information is useful. It tells us that the failure may be elsewhere in the chain. Perhaps the information isn't being retrieved. Perhaps another source dominates. Perhaps the model already had the correct answer. Perhaps product identity was never the original problem.

Why we start small

A small product set makes causality easier to inspect. Instead of integrating an enterprise catalog and hoping something improves, we can trace individual products through:

Baseline → Product Truth → Publication → AI retrieval → Answer → Re-test

Only after that mechanism is understood does scaling become interesting.

The first question is therefore not how quickly can we integrate the whole catalog? It is can we demonstrate that explicit Product Truth produces a measurable improvement in how AI identifies and represents these products?

That is what the pilot is designed to discover.

Before trying to improve how AI understands a million products, prove that you can change what it understands about ten.