How to Build a Product Knowledge Graph Without Losing Source Evidence

Start with a question the business needs to answer

A knowledge graph is useful when it improves a repeatable decision. Begin with questions such as which replacement part is approved for this machine, which supplier records refer to the same product, which product claims are supported by a current document, or which organisation owns a particular brand. Avoid beginning with a goal to connect everything.

Write the expected answer and the evidence a reviewer would need to trust it. A fitment answer, for example, may require the product identity, machine make and model, production range, position, source document, source date and review status. That list becomes the first slice of the model.

M.I.A.I Knowledge Graph is designed to connect entities, evidence and relationships into reusable business knowledge. Its approved capabilities cover canonical entities, relationship modelling, evidence provenance and reusable knowledge access, including product-to-application links, duplicate resolution and evidence-aware answers.

Separate entities, attributes and relationships

An entity is a thing with its own identity: a product, product variant, machine model, manufacturer, organisation, document or location. An attribute is a value that describes an entity, such as a model name, weight or publication date. A relationship connects two entities, such as manufactured-by, compatible-with, supersedes or evidenced-by.

The distinction prevents a common catalogue problem. If a machine application is stored only as free text inside a product description, it cannot be reviewed, queried or updated reliably. When the machine model is an entity and compatibility is an explicit relationship, the business can inspect all supporting claims, find conflicts and reuse the same knowledge in search, product pages and support tools.

The W3C RDF model describes graph statements as subject-predicate-object triples. That is a useful mental model even when the first implementation uses relational tables or documents. The important point is that the relationship has an explicit direction and meaning rather than being inferred from a shared text field.

• Entity: product P-1042
• Relationship: is compatible with
• Entity: machine model M-208
• Qualification: front idler position and applicable production range
• Evidence: supplier bulletin B-77, page 4
• Status: reviewed and approved on a recorded date

Create canonical identities without erasing source records

A canonical entity represents the business's current view of one real thing. It should have an internal stable identifier that does not depend on a title, URL or supplier description. Source records remain linked to it with their own identifiers, values and timestamps.

Do not merge records merely because their names resemble each other. Product titles, company names and model descriptions contain abbreviations, punctuation differences and reused words. Strong evidence can include a governed SKU, GTIN, manufacturer part number, platform ID, company registration number or an approved composite key. The acceptable evidence differs by entity type.

Entity resolution should return a decision and its basis: confirmed same entity, possible match requiring review, or separate entity. Preserve rejected and superseded match decisions so the next import does not recreate the same ambiguity. If two source records conflict, the graph can connect both to the canonical entity while keeping the conflicting claims separate.

Define a small relationship vocabulary

Relationship names are part of the business contract. Define each term, its direction, permitted entity types and whether it is symmetric, transitive or time-bound. Related-to is rarely precise enough for an operational decision.

For products, useful distinctions may include is-variant-of, replaces, is-replaced-by, is-compatible-with, is-consumable-for, manufactured-by and distributed-by. Schema.org's Product vocabulary illustrates several distinct product connections, including isVariantOf, isRelatedTo, isSimilarTo and isConsumableFor. These labels should not be treated as interchangeable.

Prefer one approved relationship over several near-duplicates. If one team uses fits, another applies-to and another compatible-with, decide whether they have the same business meaning. Where the meaning genuinely differs, keep separate terms and document the difference. Consistent vocabulary makes queries, validation and user explanations dependable.

Treat compatibility as a qualified claim

Many business relationships need more context than a simple line between two nodes. Product compatibility may depend on machine serial range, year, engine, configuration, position or regional variant. Supplier relationships can have contract dates and territories. Organisational ownership changes over time.

Represent that context on a relationship record or assertion entity. Store the subject, relationship type, object, qualifiers, effective dates, evidence, confidence or review status, and responsible owner. Do not hide qualifications in a note that applications cannot interpret.

The W3C RDF specification notes that relationships can change over time and that sources may provide different graph states at different times. In practical terms, do not overwrite yesterday's approved relationship without history. Close its valid period, create the revised assertion and retain the reason for the change.

Attach provenance to claims, not just files

Saving a source PDF in a folder is not enough. Link the precise claim to the source record, document version, page or row, extraction method, capture time and reviewer. A user should be able to move from an answer to the assertion and then to the evidence that supports it.

The W3C PROV-O model provides concepts for describing entities, activities and agents, including derivation, generation and attribution. A business implementation does not need to expose that vocabulary to every user, but it should preserve the same questions: what was this claim derived from, what process created it, and who or what was responsible?

Keep source evidence immutable where practical. If a supplier webpage changes, retain the captured version or checksum permitted by the source agreement. If a spreadsheet is corrected, create a new source version rather than silently changing the evidence behind an existing approval.

• Source system and source record identifier
• Document version, URL, page, row or section
• Captured value and capture timestamp
• Transformation or extraction method
• Reviewer, decision and decision date
• Validity period, revision and supersession links

Handle conflicting claims visibly

A graph becomes dangerous when it turns disagreement into false certainty. Two suppliers may provide different dimensions, a manufacturer document may supersede an old bulletin, or an ERP description may disagree with a product-data sheet. Store each assertion with its evidence before selecting a preferred value.

Precedence rules should be explicit and limited to a domain. The ERP may own sellable SKU status, the manufacturer may own technical compatibility, the PIM may own approved marketing copy and a commerce platform may own its destination ID. A recently edited record is not automatically the most authoritative record.

When rules cannot resolve a conflict, place it in a review queue with the affected entities, values, sources and downstream uses. Continue serving the last approved assertion where safe, label uncertainty where necessary and block high-risk publication when there is no trustworthy answer.

A concrete example: one part, three systems and two machine models

Consider a distributor with an idler recorded in an ERP as item 1042, in a supplier file under a manufacturer part number and in an online store with a separate product and variant ID. The supplier spreadsheet says it fits two compact track loader models, while an older PDF lists only one.

The graph creates one canonical part entity and links each source record to it without deleting the original IDs. It creates separate manufacturer, product, machine-model and evidence-document entities. Two compatibility assertions connect the part to the machine models. Each assertion records its position, applicable range, source and review status.

The first model is supported by both the current spreadsheet and the older bulletin, so the product specialist approves it. The second appears only in the new spreadsheet and remains pending until the manufacturer evidence is checked. Storefront search and an answering application can use the approved relationship but must not present the pending one as fact.

When a revised bulletin confirms the second model, the reviewer links the new evidence and approves the assertion. The answer can now explain the fitment and cite the supporting bulletin. If the part is later superseded, a new relationship records the replacement without changing the identity or history of the original item.

Validate the graph before applications reuse it

Validation should cover identity, structure and business meaning. Check that canonical identifiers are unique, required entity types are present, relationship endpoints use permitted types and mandatory qualifiers exist. A compatibility claim without a source or review state should not reach a customer-facing application.

Add domain rules for impossible or suspicious structures. A product should not supersede itself. A variant should not belong to several unrelated parent products unless the model explicitly permits it. Circular replacement chains, overlapping validity ranges and duplicate active assertions deserve review.

Test representative queries and expected answers. Include positive cases, deliberate conflicts, incomplete evidence and revoked claims. The graph is ready for reuse only when applications can distinguish approved, pending, superseded and rejected knowledge.

Give applications only the knowledge they are allowed to use

Reusable access does not mean unrestricted access. Define views or APIs for each application. A public product finder may receive approved product relationships and customer-safe evidence labels. An internal support tool may see pending claims and reviewer notes. An audit interface may need the full provenance chain.

Return the canonical entity identifier, answer, relationship type, relevant qualifiers, status and evidence reference together. Do not give an AI assistant a flattened text export and expect it to reconstruct authority. Evidence-aware answers require structured retrieval that carries the basis of the answer into the response process.

Log which graph version and assertions supported an important answer. When knowledge changes, the business can identify affected pages, recommendations or support responses and decide whether they need refreshing.

Measure trust and reuse, not graph size

Node and relationship counts show activity, not business value. Measure duplicate entities resolved, percentage of critical assertions with evidence, time to review conflicts, stale claims detected, applications reusing approved knowledge and questions answered without manual research.

Track quality by relationship type. Product-to-application links may require complete evidence and specialist approval, while a low-risk related-content link may use a lighter process. A single completeness score can hide serious gaps in the relationships that matter most.

Review whether the graph reduces contradictory answers across channels. If product search, customer support and product pages still disagree, inspect their approved views, cache and source ownership rather than adding more data.

Knowledge graph readiness checklist

• Begin with a defined business question and expected decision.
• Give every canonical entity a stable internal identifier.
• Preserve source records and their original identifiers.
• Define relationship names, directions and permitted entity types.
• Represent qualifications and effective dates explicitly.
• Attach evidence and provenance to each important assertion.
• Keep conflicts visible until an approved rule or reviewer resolves them.
• Validate identity, structure, business rules and expected answers.
• Expose approved views appropriate to each consuming application.
• Record which assertions supported consequential answers.
• Measure evidence coverage, conflict resolution and cross-channel consistency.