What a Logistics Knowledge Graph Actually Needs to Contain

Most knowledge graphs are built on what was recorded. The useful ones include what was decided.

If you have spent time with supply chain AI vendors in the past two years, you have heard the phrase 'knowledge graph' used to mean many things, most of them different enough from each other that they should probably not share a name. A knowledge graph, in the way the term is typically deployed in product marketing, means a graph database containing normalized entities, carriers, lanes, rates, invoices, with relationships between them that allow a query engine to traverse and return connected data.

That is a useful structure. It is not sufficient for AI that takes decisions rather than answering questions. The gap between those two things is worth being precise about, because it determines whether your AI deployment produces recommendations that require human judgment to execute, or agents that actually close the loop.

Four layers, not one

A context graph that supports autonomous decision-making in logistics is built in four layers, each one enabling something the layer below it cannot.

The foundation is deep connectors and observability. You connect to everything: ERP systems, WMS, carrier portals, rate cards, market feeds. But you also connect to email, documents, calls, messages, and meeting notes. This is where most enterprise knowledge graph implementations stop short. They pull the structured record and leave the unstructured rationale behind. That rationale is where the decision context lives.

The second layer is the entity model: normalized relationships across suppliers, contracts, rates, lanes, invoices, all linked and queryable. This is the skeleton. It tells the system what exists and how entities relate to each other in the standard operational sense. Most modern data platforms build something like this.

The third layer is where the category-specific context graph begins. This is not just a general procurement graph. It models how your organization does its specific job. Your negotiated rates, including the verbal exceptions and side agreements. Your patterns, the carriers you prefer on which lanes for which reasons. Your exception histories, and critically, the rationale behind how each exception was handled. This is the layer that makes the graph yours rather than a generic data model.

Decision memory: the layer most implementations skip

The fourth layer is decision memory: captured traces of how exceptions were handled, why a shipment was expedited, why an overcharge was accepted rather than disputed, the trade-offs that were made and how they were made. This is institutional knowledge made queryable.

Decision traces are what separate a knowledge graph that answers questions from a context graph that supports autonomous action. Without decision traces, an AI agent can tell you that a carrier's invoice is 12 percent above contract. It cannot tell you whether that variance falls within the informal tolerance that the operations team established after last year's service disruption, or whether it crosses the threshold that triggers automatic dispute. The former requires access to a decision that was made in a conversation that was never recorded in any system.

“Context makes AI actionable. Data makes it informed. The difference between the two is the difference between an intern and an expert.”

The technical requirement that follows

Building this fourth layer requires two things that most enterprise data infrastructure is not currently designed to provide. First, structured capture of unstructured communication: an ingestion pipeline that reads emails, meeting transcripts, and documents and extracts decision-relevant signals alongside the transaction data those signals relate to. Second, a semantic model that links those signals to the right entities in the graph with enough precision that an agent can query them in context.

The graph that results from this is not a data store. It is an institutional memory. It is the record of how your supply chain makes decisions, which is the minimum requirement for AI that can make decisions on your supply chain's behalf.