Product Identity & Evidence Graph: Products Aren't Rows

A distributor’s catalog arrives as supplier files, PDFs and feeds: the same product under five SKUs, a spec with no source, a replacement nobody recorded. Claro resolves those fragments into a Product Identity & Evidence Graph. Every product is connected to its suppliers, variants, documents and attributes, and every value carries where it came from and how sure we are.

A spreadsheet row can hold a SKU, a description and a price. It cannot hold the fact that this SKU and that one are the same contactor, that the voltage figure came from page 3 of a datasheet or that the part was quietly superseded last quarter. That knowledge is relational, and it is exactly the knowledge an ERP, a PIM, a procurement search or an AI agent needs before it can act.

Claro treats the catalog as what it already is underneath: a graph. Resolving a duplicate creates an edge. Classifying a part creates an edge. Matching a datasheet to a SKU creates an edge. Every edge carries a source, a confidence score and a timestamp, so the result is not just a cleaner row. It is a defensible one.

The five building blocks

Identity

Identity is the resolved entity, not a SKU, not a GTIN, not a fuzzy match score, but the thing all of those point at. See product identity and entity resolution.

Relationships

Variant of, pack of, replaced by, compatible with, supplied by, same as, documented by. These edges are where operational meaning lives, and where a wrong one costs a returned order. The vocabulary is defined in product relationship types.

Evidence

Which source supports this claim? In the graph, value + source + context + timestamp = evidence. See data provenance.

Confidence

A confidence score routes the work. High-confidence resolutions flow straight through, and low-confidence ones surface for a human instead of silently shipping a bad record. See confidence score.

Decision state

Can this be accepted, does it need review, is it rejected, has it been written back? The graph records the decision and not only the data, so the next ingestion inherits it.

Any model can describe a product. Knowing which claim to trust is the work.

Language models make it cheap to extract attributes from a PDF or to draft a description. They do not tell you which of two conflicting supplier values is right, whether a datasheet belongs to this variant or its sibling, or whether two listings are the same part. The graph exists to answer those questions with evidence, so extraction becomes a source of candidate claims and not a source of truth.

Why a graph, and not a bigger table

Tables store products. Relationships are what your business actually runs on, and tables force you to flatten them: one row per SKU, with the connections implied in a human’s head or a lookup column nobody maintains. Scale that to a multi-supplier catalog and the implied knowledge rots. Duplicates multiply, supersessions go unrecorded and specs drift from their source.

Because every edge is scored and sourced, the graph gets more trustworthy the more it is used. Every accepted match, rejected candidate, manufacturer alias and attribute correction becomes reusable catalog knowledge that survives the next supplier feed. That is the whole claim in one line: your catalog should get smarter every day. The argument in full is in your catalog is already a graph.

How the graph is built

1. Ingest and preserve

   Supplier files, PDFs and feeds are ingested with the raw record kept. Nothing is overwritten.

2. Normalize

   Identifiers, units and manufacturer names are standardized, with the original text retained.

3. Resolve identity

   Records are matched to existing identities or a new one is created. Near-misses are stored as NOT_SAME_AS.

4. Attach evidence

   Values are linked to the document, page and supplier that support them, each with a confidence score.

5. Route by confidence

   High-confidence results are accepted. Ambiguous or conflicting ones go to a reviewer, and the decision is stored.

6. Write back and monitor

   The canonical product record is written to ERP, PIM and channels. New supplier files re-enter the same loop.

For a hands-on walkthrough of the data model, see how to build a product evidence graph.

What it changes for each consumer

How to tell if you need one

You likely need an identity and evidence layer if several of these are true:

• The same product exists under more than one SKU or supplier code.
• Supplier files arrive in different formats and are reconciled by hand.
• Nobody can say which datasheet supports a given specification.
• Replacements and compatible parts are tracked in notes or memory.
• You are preparing the catalog for AI search or agents and cannot say which values to trust.

The vocabulary, in order

This is the reading path through the cluster:

1. Semantic product layer: where the graph sits relative to ERP, PIM and PLM.
2. Product identity: the resolved entity.
3. Entity resolution: the process that produces it.
4. Canonical product record: the operational object.
5. Product identity graph: how identity decisions persist.
6. Product ontology and product knowledge graph: meaning and structure.
7. Data provenance and confidence score: the trust mechanism.
8. Agentic commerce: where the data is consumed.

Browse the topic hubs: Product identity and Product graphs & semantics.

Terminology used across Claro

Related

FAQ

What is a Product Identity & Evidence Graph? +

It is Claro’s model of the catalog: every product connected to its suppliers, variants, documents and attributes, with a source, confidence score and timestamp on every value and relationship. It resolves fragmented supplier records into trusted product identities.

How is it different from a PIM? +

A PIM manages and publishes product content per record. The Product Identity and Evidence Graph sits upstream and alongside it, resolving which records are the same product, linking evidence and relationships, and writing resolved values back to the PIM and ERP.

Is this a knowledge graph? +

It is a product knowledge graph focused on two things: resolving identity and attaching evidence. Every claim in it is traceable to a source and carries a confidence score, which is what makes it usable for write-back and for AI agents.

What do I need to start? +

A sample product family, the supplier files and documents that describe it, and a definition of which relationships matter for your decisions. A narrow pilot on one family is enough to show what resolves, what conflicts and what is missing.

Does it replace my ERP or PIM? +

No. The ERP and PIM remain the systems of record. The graph resolves identity and evidence upstream and writes decision-ready product data back to them.