Four Layers of a Supply Chain Context Graph
March 25, 2026
•
mins
The architecture is not one system. It is four layers, each enabling something the layer below it cannot.
The term context graph gets used loosely in supply chain AI conversations to mean many things — sometimes a knowledge graph with unstructured data, sometimes a semantic layer over a data warehouse, sometimes simply a graph database with logistics entities. The precision matters because the architecture determines what the AI built on top of it can actually do.
A context graph that supports autonomous decision-making in supply chain operations is not one system. It is four layers, each one enabling capabilities that the layer below it cannot support on its own. Understanding what each layer does, and what breaks when any one of them is absent, is the clearest way to evaluate whether a deployment is positioned to produce recommendations or decisions.
Layer 1: Deep connectors and observability
The foundation layer connects to everything that contains operationally relevant data — ERP systems, TMS platforms, WMS, carrier portals, market rate feeds, contract management systems. This is table stakes for any supply chain data platform. What distinguishes a context graph foundation from a standard data integration is that it also connects to the channels where decisions actually happen: email threads, documents and PDFs, Slack and Teams messages, call transcripts, meeting notes. These are not supplementary. They are where the institutional reasoning that governs operations lives.
Without this second category of connection, the graph knows what was transacted but not why decisions were made. That gap makes the difference between AI that can answer questions about the past and AI that can make decisions about the future.
Layer 2: Entity model and knowledge index
The second layer normalizes the data from all connected sources into a unified entity model: suppliers, contracts, rates, lanes, invoices, shipments, SKUs, carriers, cost centers, compliance records — all linked and queryable. This is the skeleton of the graph. It answers the question of what exists and how entities relate to each other in the standard operational sense.
![The architecture is not one system. It is four layers, each enabling something the layer below it cannot. The term context graph gets used loosely in supply chain AI conversations to mean many things — sometimes a knowledge graph with unstructured data, sometimes a semantic layer over a data warehouse, sometimes simply a graph database with logistics entities. The precision matters because the architecture determines what the AI built on top of it can actually do. A context graph that supports autonomous decision-making in supply chain operations is not one system. It is four layers, each one enabling capabilities that the layer below it cannot support on its own. Understanding what each layer does, and what breaks when any one of them is absent, is the clearest way to evaluate whether a deployment is positioned to produce recommendations or decisions. Layer 1: Deep connectors and observability The foundation layer connects to everything that contains operationally relevant data — ERP systems, TMS platforms, WMS, carrier portals, market rate feeds, contract management systems. This is table stakes for any supply chain data platform. What distinguishes a context graph foundation from a standard data integration is that it also connects to the channels where decisions actually happen: email threads, documents and PDFs, Slack and Teams messages, call transcripts, meeting notes. These are not supplementary. They are where the institutional reasoning that governs operations lives. Without this second category of connection, the graph knows what was transacted but not why decisions were made. That gap makes the difference between AI that can answer questions about the past and AI that can make decisions about the future. Layer 2: Entity model and knowledge index The second layer normalizes the data from all connected sources into a unified entity model: suppliers, contracts, rates, lanes, invoices, shipments, SKUs, carriers, cost centers, compliance records — all linked and queryable. This is the skeleton of the graph. It answers the question of what exists and how entities relate to each other in the standard operational sense. [INFOGRAPHIC 1] Visual: The four-layer stack as a building architecture. Layer 1 (foundation): Deep connectors — ERP, TMS, WMS, email, documents, calls, market feeds. Color: neutral/grey. Layer 2: Entity model — all supply chain entities linked and queryable. Color: medium brown. Layer 3: Category context graph — category-specific logic, your rates, your exceptions, your patterns. Color: orange. Layer 4 (top): Decision memory — institutional reasoning made queryable, decision traces. Color: bright orange. Each layer labeled with what it enables the layer above it to do. Show the building as incomplete without all four. Most enterprise data platforms build something like Layer 2. It is necessary but not sufficient. A well-constructed entity model supports sophisticated querying and reporting. It does not support autonomous action, because it does not contain the reasoning that governs how the entities interact in your specific operational context. Layer 3: Category-specific context graph The third layer is where the context graph becomes yours rather than a generic data model. It captures how your organization does its specific job: your negotiated rates, including the verbal exceptions and informal amendments that were never updated in the contract system. Your carrier preferences and the rationale behind them — why procurement prefers one carrier over another on a specific lane, even when the contracted rate is slightly higher. Your exception patterns and the reasoning behind how each type of exception has been handled. This layer requires ingesting and interpreting the unstructured content connected at Layer 1. The email where an operations director agreed to a rate tolerance during a capacity crunch. The QBR deck that documented carrier performance commitments that never made it into the contract. The exception approval note that explained why a particular charge was accepted rather than disputed. These are the inputs that make Layer 3 specific to your supply chain rather than to supply chains in general. “Layer 3 is what makes the context graph yours. Without it, the AI knows about supply chains. With it, the AI knows about your supply chain.” Layer 4: Decision memory The fourth layer is what most AI deployments are missing when they describe their system as a knowledge graph: decision memory — captured traces of how exceptions were resolved, why a rate was accepted or disputed, what trade-offs were made and under what conditions. Decision traces are not logs. They are structured records of the reasoning behind decisions, linked to the entities and context that produced them. Decision memory is the layer that enables AI to be accountable rather than just accurate. When an AI agent takes a decision — approves an invoice, initiates a dispute, routes an exception — the reasoning should be traceable. What context informed the decision? What precedent applied? What threshold was crossed? Without Layer 4, the agent takes decisions that cannot be explained. In a regulated finance environment, inexplicable decisions are not trustworthy decisions, regardless of their accuracy rate.](https://cdn.prod.website-files.com/69a9744c90c7ff7e8784c3c9/6a2ed42a3abdfa319202c98d_Infographic_01_%20Four%20Layers%20of%20a%20%20Supply%20Chain%20Context%20Graph.webp)
Most enterprise data platforms build something like Layer 2. It is necessary but not sufficient. A well-constructed entity model supports sophisticated querying and reporting. It does not support autonomous action, because it does not contain the reasoning that governs how the entities interact in your specific operational context.
Layer 3: Category-specific context graph
The third layer is where the context graph becomes yours rather than a generic data model. It captures how your organization does its specific job: your negotiated rates, including the verbal exceptions and informal amendments that were never updated in the contract system. Your carrier preferences and the rationale behind them — why procurement prefers one carrier over another on a specific lane, even when the contracted rate is slightly higher. Your exception patterns and the reasoning behind how each type of exception has been handled.
This layer requires ingesting and interpreting the unstructured content connected at Layer 1. The email where an operations director agreed to a rate tolerance during a capacity crunch. The QBR deck that documented carrier performance commitments that never made it into the contract. The exception approval note that explained why a particular charge was accepted rather than disputed. These are the inputs that make Layer 3 specific to your supply chain rather than to supply chains in general.
“Layer 3 is what makes the context graph yours. Without it, the AI knows about supply chains. With it, the AI knows about your supply chain.”
Layer 4: Decision memory
The fourth layer is what most AI deployments are missing when they describe their system as a knowledge graph: decision memory — captured traces of how exceptions were resolved, why a rate was accepted or disputed, what trade-offs were made and under what conditions. Decision traces are not logs. They are structured records of the reasoning behind decisions, linked to the entities and context that produced them.
Decision memory is the layer that enables AI to be accountable rather than just accurate. When an AI agent takes a decision — approves an invoice, initiates a dispute, routes an exception — the reasoning should be traceable. What context informed the decision? What precedent applied? What threshold was crossed? Without Layer 4, the agent takes decisions that cannot be explained. In a regulated finance environment, inexplicable decisions are not trustworthy decisions, regardless of their accuracy rate.
![The architecture is not one system. It is four layers, each enabling something the layer below it cannot. The term context graph gets used loosely in supply chain AI conversations to mean many things — sometimes a knowledge graph with unstructured data, sometimes a semantic layer over a data warehouse, sometimes simply a graph database with logistics entities. The precision matters because the architecture determines what the AI built on top of it can actually do. A context graph that supports autonomous decision-making in supply chain operations is not one system. It is four layers, each one enabling capabilities that the layer below it cannot support on its own. Understanding what each layer does, and what breaks when any one of them is absent, is the clearest way to evaluate whether a deployment is positioned to produce recommendations or decisions. Layer 1: Deep connectors and observability The foundation layer connects to everything that contains operationally relevant data — ERP systems, TMS platforms, WMS, carrier portals, market rate feeds, contract management systems. This is table stakes for any supply chain data platform. What distinguishes a context graph foundation from a standard data integration is that it also connects to the channels where decisions actually happen: email threads, documents and PDFs, Slack and Teams messages, call transcripts, meeting notes. These are not supplementary. They are where the institutional reasoning that governs operations lives. Without this second category of connection, the graph knows what was transacted but not why decisions were made. That gap makes the difference between AI that can answer questions about the past and AI that can make decisions about the future. Layer 2: Entity model and knowledge index The second layer normalizes the data from all connected sources into a unified entity model: suppliers, contracts, rates, lanes, invoices, shipments, SKUs, carriers, cost centers, compliance records — all linked and queryable. This is the skeleton of the graph. It answers the question of what exists and how entities relate to each other in the standard operational sense. [INFOGRAPHIC 1] Visual: The four-layer stack as a building architecture. Layer 1 (foundation): Deep connectors — ERP, TMS, WMS, email, documents, calls, market feeds. Color: neutral/grey. Layer 2: Entity model — all supply chain entities linked and queryable. Color: medium brown. Layer 3: Category context graph — category-specific logic, your rates, your exceptions, your patterns. Color: orange. Layer 4 (top): Decision memory — institutional reasoning made queryable, decision traces. Color: bright orange. Each layer labeled with what it enables the layer above it to do. Show the building as incomplete without all four. Most enterprise data platforms build something like Layer 2. It is necessary but not sufficient. A well-constructed entity model supports sophisticated querying and reporting. It does not support autonomous action, because it does not contain the reasoning that governs how the entities interact in your specific operational context. Layer 3: Category-specific context graph The third layer is where the context graph becomes yours rather than a generic data model. It captures how your organization does its specific job: your negotiated rates, including the verbal exceptions and informal amendments that were never updated in the contract system. Your carrier preferences and the rationale behind them — why procurement prefers one carrier over another on a specific lane, even when the contracted rate is slightly higher. Your exception patterns and the reasoning behind how each type of exception has been handled. This layer requires ingesting and interpreting the unstructured content connected at Layer 1. The email where an operations director agreed to a rate tolerance during a capacity crunch. The QBR deck that documented carrier performance commitments that never made it into the contract. The exception approval note that explained why a particular charge was accepted rather than disputed. These are the inputs that make Layer 3 specific to your supply chain rather than to supply chains in general. “Layer 3 is what makes the context graph yours. Without it, the AI knows about supply chains. With it, the AI knows about your supply chain.” Layer 4: Decision memory The fourth layer is what most AI deployments are missing when they describe their system as a knowledge graph: decision memory — captured traces of how exceptions were resolved, why a rate was accepted or disputed, what trade-offs were made and under what conditions. Decision traces are not logs. They are structured records of the reasoning behind decisions, linked to the entities and context that produced them. Decision memory is the layer that enables AI to be accountable rather than just accurate. When an AI agent takes a decision — approves an invoice, initiates a dispute, routes an exception — the reasoning should be traceable. What context informed the decision? What precedent applied? What threshold was crossed? Without Layer 4, the agent takes decisions that cannot be explained. In a regulated finance environment, inexplicable decisions are not trustworthy decisions, regardless of their accuracy rate.](https://cdn.prod.website-files.com/69a9744c90c7ff7e8784c3c9/6a2ed440b79970e94d7df360_Infographic_02_%20Four%20Layers%20of%20a%20%20Supply%20Chain%20Context%20Graph.webp)
