Build a Product-to-Content Knowledge Graph

A page about sharpening a hand plane and a listing for a vintage plane share a phrase. That is enough for a crude related-item widget. It is not enough to establish that the article applies to the particular tool, that the tool is complete, or that the reader should buy it.

A product-to-content knowledge graph should record identifiable things and evidence-backed relationships between them. It needs to distinguish general concepts from actual units, documented facts from proposed interpretations, and useful reading from commercial suitability. The graph becomes valuable when those distinctions improve a decision and remain maintainable as the records change.

This chapter of The Age of AI Leverage uses a hypothetical vintage bench plane as a worked example. The object and its records are teaching illustrations. The design begins with Salars.net’s public content structure and proposes a broadly useful relationship layer; it does not describe private inventory or a deployed commerce graph.

Explain the graph in ordinary terms

A graph contains nodes and edges. A node represents a thing: an article, an actual product unit, a product type, a source, a claim, or a reader need. An edge represents a relationship: explains, supports, has attribute, fits under stated conditions, or is currently offered.

The terms sound technical, but the underlying idea is familiar. A well-organized reference file connects a source to a statement, an object to its measurements, and a guide to the question it answers. The graph makes those connections explicit enough for a system to inspect.

A list of tags is less specific. Both the sharpening guide and the plane may carry “woodworking.” That tag says they concern a broad topic. It cannot establish which part of the guide applies or whether the listed unit has the component the method requires.

The graph’s purpose is therefore more than grouping. It should explain why two records connect, what evidence supports the relation, and when the relation needs review. A recommended link becomes a reasoned proposal rather than a coincidence of words.

The website business-system chapter describes where this layer sits. It interprets maintained information and proposes useful connections; it should not replace the authoritative article or product record.

Give different kinds of things different identities

A product type and a unique product unit are not the same node. “Bench plane” is a class. A particular used plane has its own condition, dimensions, missing parts, availability, and evidence. A statement about the class cannot automatically become a statement about that unit.

Likewise, an article and a claim inside it differ. An article can discuss several materials and methods. A product-specific recommendation may depend on only one supported paragraph. Linking to the whole page without identifying the relevant relation can conceal that narrow scope.

Use stable identifiers for the records that need continuity. The product’s display name can change without becoming a different object. An article can receive a revised title while keeping the same identity and route. A source can have versions that matter to the supported claim.

Avoid merging nodes because their names look similar. Two tools may share a model description while differing in production period or configuration. Two suppliers may use similar trading names. A model can suggest a match, but the system should preserve uncertainty until the evidence resolves identity.

For the hypothetical plane, separate the physical unit, the general type, its photographed marking, a measured dimension, the maintenance article, and the claim that a certain procedure applies. This structure prevents the general guide from silently authenticating the object.

Use relationship names that carry a meaning

An edge labeled “related” is easy to create and hard to evaluate. A more precise edge states the intended relationship. The sharpening article explains care for a component type. The unit has a verified component of that type. A reader asks how to maintain it. These are distinct links in the reasoning.

Consider a proposed minimal relationship set:

These definitions are proposed design choices. A real implementation should choose the smallest set that supports its decisions. More relation types can improve precision while increasing maintenance. The graph should earn that complexity.

An explicit relationship also makes disagreement manageable. An editor can approve that a guide explains sharpening while declining that a particular tool fits a beginner. The system need not throw away the useful connection because the stronger commercial claim is unsupported.

Store the evidence beside the claim

For an actual unit, a measurement should identify who or what supplied it, the relevant unit, the method or source, and when it was checked. A photograph can support a visible marking. It may not establish the object’s full history or authenticity.

The hypothetical plane’s record might contain a verified blade width and a photographed stamp. An interpretation about production period would need appropriate supporting evidence and qualification. AI should not generate a plausible origin story to fill a missing field.

A useful claim record separates value, evidence, interpretation, and status. “Blade width measured at a stated dimension” is a supported attribute if the record establishes it. “Likely compatible with this procedure” is an inference that may depend on other conditions. “Manufacturer unknown” can be the honest maintained state.

Retain the relevant source version. An article that once recommended a method may later narrow its advice. The graph should know whether the recommendation still depends on the old text. Otherwise the visible page and its automated connections can disagree.

This is the same principle developed more broadly in provenance and auditability. The graph is useful when a person can follow the recommendation back to the evidence, not merely when the software can traverse a large network.

Let AI propose edges without inventing support

A model can help identify likely topics, find candidate related articles, and suggest a relationship description. That assistance is valuable when a site has many pages. The proposed edge should still pass a relevance and evidence check.

For the plane, the assistant might propose a sharpening guide, a condition-assessment article, and a shipping-cost explanation. Each serves a different need. The editor should verify that the actual content fits the relation and that the anchor text does not claim more than the page answers.

A model’s confidence is not a substitute for the evidence requirement. It may recognize a familiar tool name while confusing a component or version. It may infer compatibility from a broad category. The system should mark such proposals as candidates, not verified facts.

Ordinary checks can handle route existence, required fields, known identifiers, and current offer state. A person can review a small set of proposed relations where judgment matters. This is simpler and more traceable than asking a model to approve an entire recommendation chain in one paragraph.

An explicit unknown field also prevents a later component from treating an omitted value as a default. The distinction belongs in the record before another system uses it.

The graph should allow abstention. If no existing article genuinely helps, the result can be no contextual link. If product fit remains uncertain, the system can offer the explanatory guide without recommending the product. Absence of an edge is preferable to unsupported certainty.

Separate editorial relevance from purchase eligibility

An article can be relevant to an object that is unavailable, unsafe to offer, or outside the business’s selling scope. A guide may still help a reader identify or understand it. Editorial relevance and commercial eligibility must remain separate states.

For the hypothetical plane, a general maintenance article might remain useful after the unique unit sells. The offer edge should change to unavailable; the explanatory relation can remain if the content still fits. The inventory-to-content chapter develops this durable informational use.

Eligibility can also depend on facts outside the topic. Product safety, rights to descriptions and images, seller authority, and applicable rules may affect what can be offered. A large number of related articles cannot compensate for a failed eligibility condition.

A commercial relation should identify the need it serves. Someone researching historical tools may want evidence, while someone equipping a workshop may care about dimensions, condition, and practical use. The same object can enter different paths without the system assuming every reader wants to buy it.

The content-commerce chapter addresses relationship disclosure and editorial independence. In the graph, those considerations become maintained conditions rather than a generic assurance that every recommendation is helpful.

Keep availability and terms current

Availability is time-sensitive. A source saying that a unique item was offered last week cannot establish that it is available now. A recommendation system needs the current authoritative state or a truthful inability to confirm it.

The same applies to price, shipping, and return terms. A content article can explain how a cost works without holding today’s offer. The graph should distinguish durable explanation from changing commercial facts.

Google’s product structured-data guidance describes communicating product information such as price, availability, and shipping. The graph can help keep those facts consistent with visible records, but markup does not establish truth or guarantee display. Google guidance.

Define a freshness rule for each relevant relationship. A general concept relation may need review when the article changes. An available-offer relation may need a current check whenever the recommendation is shown. An interpretation based on a newly contested source may need immediate editorial review.

When the authoritative source is unavailable, fail according to consequence. A related-reading link can often remain if the page is verified. A purchase promise should not rely on a stale snapshot. The system can say it cannot confirm the commercial condition and route the reader appropriately.

Work through a recommendation path

Imagine the reader asks whether a particular plane would suit a basic furniture project. The proposed system first identifies the stated task. It then checks the unit’s verified attributes, condition, and any limitations relevant to that task.

A general article may explain how plane types differ. Another may explain why blade condition matters. Those pages help the reader understand the decision, but they cannot establish the unit’s actual condition. The recommendation needs the unit-specific evidence too.

If the record verifies suitable dimensions but leaves a critical component uncertain, the system should not recommend the item as ready for use. It can explain the confirmed facts and ask a responsible person to resolve the missing condition. This is useful assistance without a premature sale.

If the item is sold, the system should preserve the explanatory path and make the offer state clear. It might identify another candidate only after verifying that candidate’s facts. A replacement cannot inherit suitability just because it shares the old product’s category.

The reader-facing explanation should be short enough to use: which verified facts support the suggestion, what remains uncertain, and which guide helps interpret the decision. The full graph exists to support that answer, not to burden the reader with internal classifications.

Evaluate the graph by decisions

A large node count or many edges does not prove usefulness. Evaluate whether proposed connections help readers and operators make better decisions. The graph’s size is an operating measure, not its outcome.

Build a representative evaluation set. Include clear matches, misleading word matches, outdated offers, missing attributes, and cases with no appropriate product. The expected result should state which relation is justified and which stronger relation must be withheld.

Test after source changes. If an article narrows a recommendation or a product becomes sold, the related output should update appropriately. A graph that works only with a static demonstration lacks evidence about maintenance.

Measure review burden. If editors reject most proposed edges, investigate the relation definitions or candidate method. If the accepted edges require sustained correction later, the apparent automation benefit may disappear. Count the work of keeping the graph truthful.

Keep the limits of the evaluation visible. A set of test cases can demonstrate behavior on those cases. It does not prove every future recommendation will fit. The system should preserve boundaries and review where consequences or uncertainty warrant them.

Begin with a small maintained subset

A simple implementation can use existing article and product records plus a relationship table. It need not begin with a specialized database or another publishing pipeline. The first question is whether explicit relations improve a specific reader path.

Choose a few articles and authorized product examples. Define the useful relation types, the required evidence, and the review owner. Record source references and freshness conditions. Prepare candidate links without automatically publishing them.

Use a deterministic validator for stable invariants: known identities, valid routes, required support for approved edges, and appropriate offer state. A separate review addresses semantic relevance and factual interpretation. Each check should correspond to a real failure that could affect the decision.

Preserve correction history where it matters. If an edge was removed because the product did not fit, retain the reason so the assistant does not keep proposing it. If an article changes, identify the dependent relations rather than rescanning every possible pair without purpose.

Expand only when the small subset remains useful at sustainable maintenance cost. The product opportunity score can use some of the graph’s evidence later, but it should not convert missing relations into invented product certainty.

AI Leverage in Practice

What changed? AI can help propose many semantic connections between content and products. The challenge shifts toward representing what those connections mean and verifying the support behind them.

What can you do today? Choose one reader need, several relevant articles, and a verified product example. Give each a stable identity. Define a handful of relation types and require evidence for approved edges. Test a misleading match, a sold item, a missing attribute, and an abstention case before showing recommendations.

What becomes possible later? A maintained graph can support more helpful reading paths, grounded concierge answers, and product investigation. These uses require current facts and bounded authority. A dense network alone cannot establish product suitability or commercial value.

A connection with a reason

The sharpening guide and the vintage plane can belong together, but the relation needs a reason. Which component does the guide address? What is known about the unit? What does the reader need? What remains unresolved?

A useful graph keeps those questions attached to the link. It lets the site connect knowledge without turning resemblance into evidence. The reader receives a clearer next step, and the operator gains a relationship it can explain, correct, and maintain.

Return to the AI section, or continue through the series hub.

Sources

• Google Search Central, Introduction to Product structured data, checked October 7, 2026.
• Provenance and auditability.
• Turn unique inventory into useful content.

The graph design, object, records, and recommendation paths are proposed teaching examples. No private catalog or deployed recommendation result is represented.