The Anatomy of a Decision: A Blueprint for Enterprise Context and Decision Intelligence

A blueprint for enterprise context and decision intelligence, exploring the three dimensions of knowledge, where today’s debate is looking, and how to set the whole thing up.

Most enterprise AI today is built to answer a query and stop, which is why it struggles to show its returns. 88% of enterprise AI pilots never reach production, and only about a quarter of those that do deploy deliver measurable return. It is easy to blame the AI model itself, but the real flaw lies in system design. Most systems treat choices as isolated answers without tracking the history, human accountability, or broader impact on other business decisions.  

The fix is not a bigger model on the same structure. It is building three things most enterprises only ever build one of: (a) what the organization knows, (b) what each role actually needs to ask, and (c) how that knowledge changes over time. We call this the anatomy of a decision, and the durable asset isn’t any one of these on its own. It’s the governed circulation between them. 

Where the Industry is Actually Looking 

Let’s first understand what we mean when we say context. In an enterprise, the whole idea of context is meant to help with one thing: making decisions that help move real enterprise KPIs. It thus makes sense to look at a decision as a base for understanding what we need to look at as context. Every enterprise decision draws on three dimensions of knowledge: supply (what is known), demand (what a role needs to ask), and motion (how that knowledge changes and circulates).

A role’s question (demand) activates the relevant slice of the corpus (supply); together they produce a decision; the verified outcome flows back as motion, compounding the corpus and raising the next question.

There is a live debate about how enterprises should represent meaning for AI: semantic layers, ontologies, knowledge graphs, and, at the leading edge, context graphs that capture why a decision was made. While each is a considerable improvement, it is evident that all four sit on a single dimension – supply. These tools are increasingly capable of building what is known. However, none of these models addresses the specific questions a role is trying to answer, and none treats business processes as a governed loop rather than a static record. 

The 2026 debate runs along a ladder that lives inside the Supply dimension. Demand, and Motion as a governed loop, are the parts the debate has barely named.

While most enterprises are still working to standardize basic data metrics, advanced industries like healthcare and life sciences have already moved forward by investing in ontologies and knowledge graphs. Fewer still have reached or even defined a true context graph. While this foundational work is valuable, it alone cannot capture how a decision is actually made. It builds supply but does not ask the right question or close the loop. 

To build true context within an enterprise it is important to look at all three of the faces and build them out as reachable elements that can then steadily compound in value over time. Any system needs to keep all three of these faces active, alive, and interconnected  

Understanding the Three Dimensions of Knowledge 

Let’s try to understand what each face really is, what it needs to contain, and where it needs to sit.  

Supply — what is known 

This is the curated corpus: definitions, metrics, policies, and the relationships between them, the verified record of what the organization considers as fact. Most semantic layers and knowledge bases already build a version of this foundation. While necessary, it remains inactive until a specific question pulls it off the shelf. It is important to understand how Supply that exists within organizations can be enhanced in a new world where access to unstructured data has made the world of data available to us much larger.  

Most elements within supply are about the data, the metadata, the relations between them, metrics, and KPIs that the organization uses, and any deterministic models that might sit within the enterprise. 

 Supply currently sits within data warehouses, ERP systems, documents in SharePoint, and tools that log customer touchpoints. There is a considerable portion of supply also present as tribal knowledge of various stakeholders within the enterprise, which the system needs to find a way to pull. 

Demand — what we need to know 

This is the exact dimension most programs skip, and it currently has no place in the modern context and data foundations. Every role in an organization owns a set of questions, with an expectation or standard for possible answers to those questions. For example, a finance lead and a store manager can look at identical data but require entirely different answers. The question itself, not the raw data, defines success.  

Hence, Demand is the set of recurring questions that need to be answered by the role with a defined expectation of what an answer could look like. Further, demand also captures the base principles and assumptions that enterprises operate under. Assumptions around regulation or around behavior are critical to be overlaid. While the set of questions that help make a decision is critical to capture, it is also critical to capture the business process these decisions belong to 

Demand is partially captured in Dashboards, but they are permanently hard-coded to only a few select questions, while search bars retain no context at all. Most questions are actually in a person’s head and are represented in monthly management reports or in emails that are shared between different roles 

Motion — how knowledge changes 

Knowledge compounds when it is continuously authored, derived, verified, and fed back into the system. This active motion of knowledge, whether it is recording a decision, deriving a new fact from existing data, or updating an old assumption when real-world evidence contradicts it, is what transforms a static library into a living memory. However, for this value to multiply, this motion must run as a continuous loop instead of a passive log. 

Most motion of knowledge today is not captured, and even where captured, it is not consolidated. Jira systems capture some decisions, for example, but they are never captured or consolidated. Tickets and change management workflows capture some movement of decisions, but again, they are not consolidated. Chat threads, sidebars in a meeting, and emails capture most of the motion today, but don’t find a way back to a structured schema for further use.  

While understanding motion, the key elements to capture are the trigger – what fires the change event, the change event itself – what decision was made, the outcome of the change, and any inferences that can be made based on the change for review. 

 The three dimensions of knowledge meet at the point of decision (as shown in image 1). Decision is the smallest unit that carries these three all at once.  

The Decision is the Unit that Compounds 

The three dimensions meet in one artifact, the decision record: a scoped question, an evidence-traced answer, the workflow that approved it, and a monitoring layer that says what to watch and when to revisit. A decision is not a row in a log. It is two things at once: a particular ask of supply you can read later, and a moment of motion, the act of deciding.

Left: the four-layer decision record.

Right: decisions chain across departments into a decision narrative, the structure an audit can actually follow. 

Decisions connect to each other. One choice leads to another. A simple inventory reorder is part of a store’s category plan, which is part of the company’s bigger profit strategy. Big decisions guide the smaller ones, and the small results prove whether the big strategy is working. This is exactly where traditional data systems fail. They track the separate numbers but are completely blind to the chain of decisions. 

Why the Economics Favor the Ends  

When simplified, the three dimensions are three roles played around a single loop: a human frames a question, intelligence reasons over the knowledge base, a human verifies the result, and the verified result feeds the next question.

Demand frames at the front, supply is reasoned over in the middle, motion verifies, and records at the back, and the verified decision compounds the corpus. The two ends are where human value concentrates as the middle gets cheaper. 

Modern models are making the middle of the loop, finding information, writing drafts, and breaking down problems, incredibly cheap and fast. What these models cannot do are the two ends: asking the right question and verifying that the answer is trustworthy. Those require experienced human judgment. In fact, as the machine outputs increase, the cost of oversight goes up because humans must spend more time framing the right questions and verifying the results.    

An architecture built around demand and motion is built on the part of the system that gains value as everything else gets cheaper.

Why Governance is the Strategic Advantage 

None of this works without governance. Here, governance is not a compliance checklist added on at the end. It is the core structure that makes it safe to grow. In fact, the three practices line up perfectly with the three dimensions. 

Context governs supply, Stewardship governs motion, and the Operating Model governs demand. Each is institutional rather than technological, which is why the combination is hard to copy and does not get cheaper as models improve.

• Operating Model governs demand: which role may ask what, against what evidence standard, using the organization’s existing permissions rather than a parallel set.  
• Stewardship governs motion: a federated discipline, domain owners, plus a central council, that checks any proposed change before it reaches everyone reading the same corpus.  
• Context governs supply: the verified corpus itself, kept current by stewardship and put to work by demand. 

Build the Compounding Loop with 4 Steps 

Four tactical moves can make this model work on your existing system. This turns your implementation into a series of strategic choices rather than a massive platform purchase: 

1. Start from demand, not supply 

Do not try to model the entire semantic layer upfront. Start with five to ten real questions that a specific person in a single domain asks every week, and write each as an Inquiry with its own criteria. These initial questions bring your first slice of data into play. They define exactly what a good answer looks like, ensuring your system expands only where it is needed. 

2. Make the decision, record the main artifact

Build the four-layer decision record early, backed by an evidence library so every claim traces back to its source. This shifts the dynamic from “the AI gave an answer” to “here is the decision, the evidence, the authority, and what we will watch.” This approach is also what compounds, making the body of verified decisions the asset that gains value over time. 

3. Choose where to store it 

The elements are invariants; where they live is a choice. Every piece across all three dimensions can sit inside the systems your business already runs and governs, whether that is a markdown vault, a knowledge platform, a graph, or a data warehouse. Supply is not the only piece that needs a home. Your questions and your decision history need one too. 

4. Run the loop, then widen it

Prove one loop end-to-end for one role: a scoped question, reasoning over a small corpus, a human verification, and a recorded decision that feeds the next question. From there, new roles and domains are configured, not rebuilt. The engine stays the same; only the framing of the demand-layer changes with scale.

Conclusion 

While necessary, supply is the easy part, and it does not compound on its own. Demand and motion are where actual decisions live. Decisions that are recorded, evidenced, governed, and owned by the enterprise itself become the definitive asset that gains value while everything else around it gets cheaper. 

Consequently, market leaders over the next few years will not be determined by the volume of their semantic layers or the scale of their context graphs. Competitive advantage belongs to organizations that implement all three dimensions of knowledge and orchestrate the data circulation between them, optimizing for the query logic just as rigorously as the model output, and validation loops as deeply as the underlying reasoning.