How to Build a Product Evidence Graph from PDFs, ERP and Supplier Files

Most companies do not lack product information. They lack a reliable way to connect it.

A product may exist in an ERP as an item number, in a PIM as a marketing record, in a supplier spreadsheet under another code and in technical PDFs under a model name. The evidence may exist too: declarations, certificates, safety data sheets, test reports, technical specifications, manuals and supplier statements.

The challenge is establishing which source supports which product, variant and value. A product evidence graph makes those relationships explicit.

What is a product evidence graph?

A product evidence graph is a connected view of:

• products
• models
• variants
• supplier records
• documents
• extracted values
• source locations
• review decisions
• missing evidence

It can be implemented in different technical ways. A graph database is optional. The goal is operational: for any important product claim, the team should be able to identify the product, source, evidence, scope, status and reviewer.

This guide explains how to build a first version without replacing the ERP, PIM or document repository.

Start with a narrow question

Do not begin by modeling the entire catalog. Choose one operational question.

Examples include:

• Which documents apply to each sellable variant?
• Which supplier values are safe to write to the PIM?
• Which products are missing technical evidence?
• Which marketplace listings correspond to internal products?
• Which supplier documents have expired?
• Which replacement products are genuinely equivalent?

A narrow question determines which entities and relationships are necessary. For this guide, the example question is: which documents and source values support each product and variant?

Step 1: Choose the product sample

Select a manageable sample, such as:

• one product family
• 20–100 products
• one high-risk supplier
• one category with frequent document problems
• one catalog-onboarding batch

Include difficult cases: duplicates, missing identifiers, multiple variants, revised models, old documents and conflicting values. A pilot containing only clean products will not test the workflow.

Step 2: Inventory the source systems

Create a source register.

For each source, record owner, update cadence, expected authority, identifier coverage, version handling, access method and known quality issues.

Do not declare one source universally authoritative. Different sources may own different fields.

Step 3: Preserve raw records

Keep every source record before normalization.

For a supplier row, preserve the original file, sheet, row, supplier code, description, attribute names and values. For a PDF, preserve the file, version, page, section, upload date, supplier and original filename. For a system record, preserve the system, record ID, extraction timestamp and original field values.

Do not begin by overwriting old data. The raw layer is the audit trail.

Step 4: Create the canonical product identity

The canonical product record is the central entity in the graph.

Do not assume the ERP row is automatically the canonical product. An ERP item may represent a pack, commercial bundle, local purchasing record, duplicate or market-specific version.

Step 5: Match source records to the canonical product

For each source record, determine whether it:

• represents the same product
• represents a variant
• represents a family
• represents a component
• is a duplicate
• is unrelated
• remains uncertain

Use exact identifiers, normalized identifiers, manufacturer, model, description, technical attributes, dimensions, capacity and source context.

Store the decision with status, confidence, supporting signals, reviewer, date and rejected alternatives.

Do not hide uncertain matches.

Step 6: Model family, model and variant relationships

A common failure is using one generic product level.

Create explicit relationships:

• family has model
• model has variant
• variant has pack
• product contains component
• revision supersedes revision

Then define the level for each value and document.

This prevents family-level evidence from being treated as unit-level or variant-level evidence.

Step 7: Ingest and classify documents

Create a document record for every file.

Recommended fields include document ID, document type, title, issuer, source, version, issue date, expiry date, language, original file, products mentioned, models covered, exclusions and review status.

Document types may include technical datasheet, declaration, certificate, SDS, test report, manual, supplier statement, environmental report or product brochure.

Classification should generate candidates, not final legal conclusions.

Step 8: Link documents to products and variants

For each document, create an explicit relationship.

Example: Document D-104 covers Model AX-440.

Relationship metadata may include:

• coverage level: model
• variants: A and B
• exclusions: high-temperature configuration
• valid from and valid until
• source: supplier portal
• confidence: high
• review status: approved
• reviewer: compliance team

If coverage is unclear, mark it as may cover — needs review. Do not force approval.

Step 9: Extract field-level evidence

Documents often support individual values.

For each extracted field, store attribute, original value, normalized value, unit, source document, source page or section, product level, extraction method, confidence and validation status.

The housing material requires review because the source is family-level.

Step 10: Separate source authority by field

Create an authority matrix.

Avoid one global hierarchy such as ERP always wins. The ERP may be authoritative for price and internal status but incomplete for technical attributes.

Step 11: Detect conflicts

Common conflict types include:

• two different values for the same field
• the same identifier linked to different products
• a document covering one model while the catalog uses another
• an expired document remaining active
• a supplier revision not reflected in the PIM
• a family value applied to a variant
• normalized values differing beyond tolerance

A conflict record should include product, field or relationship, source A, source B, reason, severity, owner, status and resolution.

Do not silently choose a value when policy requires review.

Step 12: Create evidence-gap states

For each required field or document, use clear statuses.

These states are more useful than a single generic readiness score.

Step 13: Define human-review policies

Not every record requires the same review.

Possible triggers include:

• no exact identifier
• conflicting high-authority sources
• document coverage inferred from text
• significant value change
• expired evidence
• family-level evidence used for a variant
• low extraction confidence
• regulatory interpretation required
• high-impact write-back

The reviewer should see a compact decision view: current value, candidate value, source evidence, product scope, transformation, conflict and recommended action.

Step 14: Approve outputs for specific systems

Approval should be contextual.

A value may be approved for internal analysis, approved for PIM, approved for marketplace export, not approved for compliance use, or approved only for selected markets.

Record the target and purpose. This prevents one approval from being interpreted too broadly.

Step 15: Export without losing provenance

Downstream systems may not support every provenance field. At minimum, retain a link back to the evidence graph.

An export may contain:

• canonical product ID
• approved value
• target unit
• status
• source reference
• last approval date
• review flag

The full graph can remain in the operational layer while ERP and PIM receive the fields they need.

Step 16: Monitor changes

The evidence graph should not be a one-time project.

Monitor new supplier files, document revisions, expiry dates, product changes, new variants, system updates, conflicts, changed source URLs and replacement products.

When a source changes, identify affected products and values. This is the practical difference between a static audit and continuous data operations.

Minimal data model

A first version can use six connected tables or entities.

This can be implemented in relational tables. A dedicated graph database is optional.

Example output

For one product, the evidence view might show:

Evidence:

• voltage → datasheet page 3 → approved
• current → datasheet page 3 → approved
• IP rating → test report page 2 → approved
• material → family brochure page 7 → needs review
• declaration → models AX-440-A/B → approved
• packaging weight → missing

That is more actionable than a folder containing five PDFs.

Where Claro fits

Claro can support the workflow from source ingestion to approved evidence.

Claro can help:

• import supplier catalogs and documents
• identify canonical products
• match source records
• extract product attributes
• preserve source locations
• normalize values and units
• connect documents to variants
• detect conflicts and missing evidence
• assign confidence
• route exceptions to review
• prepare downstream exports

Claro does not replace the ERP, PIM, document repository or compliance specialist. It provides the connected data context between them.

Implementation checklist

• The canonical product level is defined.
• Raw source records are preserved.
• Family, model and variant are distinct.
• Match decisions are explainable.
• Rejected matches are stored.
• Documents have version and scope metadata.
• Document coverage is explicit.
• Field-level source links are available.
• Normalization retains original values.
• Conflicts are visible.
• Human-review policies are documented.
• Approval is linked to purpose and target system.
• Changes and expiry dates can be monitored.
• Downstream exports retain a provenance reference.

FAQ

Do I need a graph database to build a product evidence graph? +

No. A relational database can represent the entities and relationships. The operational model matters more than the database label.

What is the difference between a document repository and an evidence graph? +

A repository stores files. An evidence graph links files and extracted values to products, variants, sources, decisions and review status.

How many products should be included in the first pilot? +

A focused set of 20–100 products is often sufficient to test identity, document coverage, conflicts and review workflows.

Should every product attribute have field-level provenance? +

Prioritize important, enriched, disputed, regulatory or frequently changing attributes. The level of detail should follow the use case and risk.

Can the evidence graph write directly to a PIM? +

Approved values can be exported or written back according to system and governance policies. Candidate and uncertain values should remain separate.

What happens when a source document changes? +

The workflow should identify affected products and values, compare versions and trigger review where required.

Conclusion

A product evidence graph does not begin with graph technology. It begins with disciplined relationships:

• this source record represents this product
• this document covers this variant
• this value came from this page
• this decision was reviewed by this team
• this evidence is missing or expired

Once those relationships are explicit, product and supplier data becomes easier to validate, update and use safely across systems.

Want to test an evidence graph on a real product family?

Claro can analyze a sample of ERP records, supplier files and PDFs and return a connected view of products, variants, sources, evidence and unresolved gaps.

Book a working session with Claro