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 

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).

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. 

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. 

The context graph sits at the top of the data maturity ladder, but it is still just a single component. It does not capture the full anatomy of a decision.

Understanding the Three Dimensions of Knowledge 

Every piece of the enterprise knowledge plays one of three roles. To steadily compound in value, the system must keep all three roles active and interconnected. 

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 have already built this foundation. While necessary, it remains inactive until a specific question pulls it off the shelf. 

Elements: Unit (the addressable container), Metadata (owner, freshness, sensitivity), Observation (a single typed fact), Relation (a typed link, the graph itself), Type (the governance template), Axiom (a rule that lets the system infer rather than just look up), Model (a learned function that produces knowledge, such as a score or a prediction, rather than storing it), and Process (a procedural object: ordered steps, a trigger, and the points where decisions get made). 

How to set it up: Focus on a single role in one domain, building only the specific data and knowledge that role actually uses. Assign a clear type and metadata to every unit from the start, as these details are easy to add during creation but costly to fix later. 

Demand — what we need to know 

A role owns a specific question, which dictates the standard for judging the answer. For example, a finance lead and a store manager can look at the identical data set but require entirely different answers. The question itself, not the raw data, defines success. 

This is the exact dimension most programs skip, and it currently has no place in modern software. Dashboards permanently hard-code only a few select questions into rigid charts, while search bars retain no context at all. 

Elements: Use Case (the outcome a role is actually working toward, grouping the inquiries that serve it), Inquiry (the stored, role-bound question, with its follow-ons), and Criterion (the threshold that decides whether an answer is fit to act on). 

How to set it up: Sit with one role and write down the five to ten questions it actually answers every week. For every question, capture the inquiry and the criterion, focusing strictly on the role rather than the person holding it. 

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. 

Elements: Trigger (what fires the event: a schedule, an upstream event, a continuous stream, or a human kick-off), Event (a change a person or agent makes, with actor, evidence, and authority attached), Outcome (what the event produces: the decision and the artifacts it is expected to deliver), Inference (a change worked out automatically from existing facts), and Signal (feedback that tells the corpus the world has moved, in either direction). 

How to set it up: Capture the decision, not the query. Give every decision a signal for what to monitor and a review step to verify changes before they roll out. 

The three dimensions of knowledge meet at the point of decision (as shown in image 1). Decision is the smallest unit that carries all three 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.

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.

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. 

• 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.