What's a knowledge graph?

A knowledge graph represents things and the relationships between them. In a business, those things might be customers, suppliers, products, contracts or decisions. Connecting them gives people and software a way to follow how one record relates to another. Hogan et al., Knowledge Graphs.

For example, a graph could connect a supplier to a purchase order, that order to a production deadline, and a purchasing decision to the evidence behind it. It can also connect the decision to what happened afterward.

That last connection is the one I keep coming back to:

Your AI helped make the decision. Did it ever find out what happened next and learn from it?

To answer that, it helps to understand three related terms: knowledge graph, ontology and context graph.

What does a knowledge graph look like?

Imagine a manufacturer deciding whether to order a critical part from a backup supplier. This is a hypothetical example, not a Nodes customer result.

The purchasing system holds the original order. A planner knows which production run needs the part. An email contains the supplier's latest delivery estimate. A manager remembers the last time the team paid for an unnecessary backup order.

A knowledge graph can represent connections such as:

The useful question becomes: which production commitments depend on this supplier, and what evidence supports the decision to buy elsewhere?

You don't have to look at a screen full of dots and lines. A useful interface might show an answer, its supporting records and the connections you need to inspect.

What is an ontology?

An ontology defines the concepts in a subject area and how those concepts relate. In business terms, it makes the meanings of things such as supplier, purchase order and delivery explicit enough for systems to use consistently. Formal ontology languages can also express logical restrictions. W3C OWL overview.

In our example, an order and a delivery are different things. One order might arrive in several deliveries. A part received at the warehouse may still be awaiting inspection.

Those distinctions matter. If one system treats "received" as "ready for production" and another doesn't, connecting their data without reconciling the meanings can produce a misleading answer.

You can start with the terms needed for one useful question. You don't need to settle every definition across the company before investigating a supplier problem.

What is a context graph?

Here, a context graph means connected information about the circumstances relevant to a decision: the evidence, people, constraints, judgments and history that help explain it.

The term has several uses. IBM describes structured context assembled for language models. A W3C Community Group focuses on mismatches between shared knowledge and the local setting in which it is interpreted. Its work is a community initiative, not a W3C standard. IBM's explanation, W3C Community Group.

For the backup order, relevant context might include how reliable the supplier's estimates have been, whether the part has a substitute, why the planner expects a delay, and when a reported port disruption became known.

A knowledge graph can already contain that information. Calling it a context graph emphasizes how the connected information serves a particular decision; it doesn't mean buying a completely separate kind of database.

What's the difference between a knowledge graph, an ontology and a context graph?

These concepts overlap. This is a practical way to distinguish their roles in the same supplier decision:

The names are useful when they help people ask better questions. The business still needs evidence that those connections improve the work.

How can a knowledge graph help AI make a decision?

Continue the hypothetical supplier example. An AI system has been asked whether the company should place a backup order.

It needs more than the most recent delivery email. The person reviewing its recommendation should be able to inspect the original commitment, current estimate, production dependency, backup quote and relevant earlier decisions. Missing or conflicting information should be visible.

The alternatives might be to buy now, wait for another update, order a smaller quantity or change the production sequence. Compare them over the same period. Include purchase and freight costs, staff effort, possible idle time, excess inventory and the uncertainty behind each estimate. Waiting may be the better option when another update will resolve an important unknown.

The relevant manager decides within the company's current approval rules. An earlier exception can inform the discussion; it doesn't authorize a new purchase.

Afterward, connect the decision to the actual deliveries, costs and production result. Keep the evidence available at the time separate from what became known later:

That connected record is what we mean at Nodes by a Decision Trace: the inspectable history of the evidence, judgment, decision, action and later result. Recorded reasoning should reflect the explanation actually given, with assumptions labeled, rather than a story invented after the outcome.

Does a knowledge graph automatically make AI learn?

No. Recording a result gives you something to learn from. It doesn't show that learning happened.

Suppose the original delivery arrived on time and the backup order went unused. That outcome challenges the earlier estimate. It doesn't, by itself, prove the manager made a bad decision. Buying a backup may have been reasonable given the information and downside at the time.

A useful review asks which assumption failed and whether the lesson applies again. Was the supplier unusually cautious? Did conditions change? Was the production risk overstated? Would a smaller backup have been sufficient?

Then test any proposed change on later, comparable decisions. Agree what improvement means, such as fewer disruptions at an acceptable total cost, and compare it with the previous process. Where feasible, also compare recommendations made with and without the retained decision history.

Keep failed and inconclusive results. A manager's preference belongs in the record as judgment that can be examined. Approval alone doesn't make it correct, and a favorable outcome alone doesn't prove the action caused it.

Who owns the knowledge graph if you change AI vendors?

The ownership terms should be explicit before production use. My position is that the company's specific knowledge and decision history should remain its asset, including when it leaves a vendor.

That standard applies to Nodes too. Our software is our IP. The customer's agreed knowledge graph and history are a separate asset. Nodes' published ownership terms describe that boundary and the role of the customer agreement. Ownership and exit.

Ask for a sample export and have someone follow a decision through it. Can they identify the records, understand the relationships, locate the sources and distinguish what was known then from what was learned later?

Changing from OpenAI to Anthropic, or to another supported model, should not require recreating that history. The replacement model still needs testing. Keeping the knowledge does not automatically preserve every workflow or provide continued use of a vendor's licensed software.

Does my business need a knowledge graph?

It may help when the same important decisions repeatedly require people to connect evidence across systems, and reconstructing those relationships is difficult or expensive.

A report, search tool or better review process may be sufficient for a simpler problem. Start with the question and assess the work required to answer it. Include the cost of connecting, maintaining and checking the information in the business case.

Our approach at Nodes starts with one business question, an accountable owner, permitted sources and a result the company can measure. The purpose of connecting company knowledge is to make that decision easier to investigate, carry out with the required authority and evaluate afterward. How Nodes works.

What should I ask an AI vendor to show me?

Bring a real decision your company is comfortable discussing and ask for five demonstrations:

1. Follow the whole decision. Show the evidence available then, the reasoning, approval, action and actual outcome.
2. Inspect a failure. Show how a disappointing result informs a proposed change to the next recommendation.
3. Test the improvement. Show evidence from later decisions, including the comparison used and the costs counted.
4. Check the context. Show the relevant company history and external changes, with sources and dates showing when they became available.
5. Compare acting and waiting. Show the estimated costs, risks and assumptions for both, including what additional information might change the decision.

Then ask to see the usable export of that history.

Bring a decision your company got wrong to the demo. Ask how the system would help you avoid repeating it, and what evidence would show that it did.

Sources

• Hogan et al., Knowledge Graphs.
• W3C OWL 2 Web Ontology Language Overview.
• IBM: What is a context graph?.
• W3C Context Graphs Community Group.

Saad Bin Shafiq is the founder of Nodes, serving data-sensitive enterprises.