The Write Path Problem:
Why Decision Capture Is
Not a Context Graph Function

The Context Graph Reality Check series established two things. Part 1 showed that metadata platforms cannot serve as context graph platforms because they sit outside the organizational write path — they observe decisions, they do not intercept them. Part 2 named the upstream prerequisite: the empty graph problem, and the three conditions an organization must satisfy before a context graph has anything meaningful to ingest. This post extends that argument one level deeper. It names the specific architectural function that closes the gap between organizational decision-making and a populated graph — and makes the case that this function belongs to Decision Intelligence architecture, not to the context graph layer.

The context graph conversation has been almost entirely about the read path. Which vendor. Which query architecture. Which applicability model returns the right context to an agent at the moment of action. That is eventually the right conversation. But it assumes something that most enterprises do not yet have: a write path that produces structured decision artifacts in the first place. That assumption is where the investment case for context graphs currently rests on air.

The Question Nobody Has Asked

Context graph platforms are being marketed on the strength of what they return. The evaluation criteria are read-path criteria: applicability scoring, temporal validity, traceability, query performance at scale. Those are the right dimensions to evaluate in a graph that already contains something worth querying.

The question the market has not asked is: how does a structured decision trace get into the graph? Not extracted, retroactively, from a Slack thread. Not reconstructed, imperfectly, from a meeting transcript. Captured — at the moment a decision is made, in the schema the graph requires, linked to the entities the decision affects.

That question points at a different architecture entirely. An architecture that has to live upstream of the graph. An architecture that has to be designed around how decisions are made, not around how the graph answers queries. That upstream architecture is the subject of this post.

Two Paths, Two Functions

Every context graph has two distinct operational paths. Understanding the difference between them is the foundation of the write path argument. Part 1 of the Context Graph Reality Check established that metadata platforms are excluded from the context graph category because they sit outside the organizational write path. This post zooms into the mechanics of what the write path actually requires as an architectural function — the two arguments operate at different levels of the same structure.

The read path is an infrastructure problem. The write path is an organizational architecture problem. They require different solutions and different ownership — and confusing one for the other is the sequencing error most context graph investments are currently making.

What Decision Capture Actually Is

The market does not yet have vocabulary for the write-path function. That gap is where category capture happens — the space between an unnamed concept and the nearest named product fills itself. So the term needs staking before the space closes.

Four properties define a capture event. When all four are present, the context graph has something it can serve with precision. When any one is missing, the graph ingests a partial record — queryable, but not capable of returning applicability determinations with the accuracy the read path promises.

The extraction approach — LLM pipelines mining communication channels after the fact — is a real capability and a necessary complement for unstructured organizational context. But extraction can only recover what was expressed. It cannot recover what was decided but never articulated, or what became precedent through repetition rather than declaration. Those gaps are not a technology problem. They are an organizational design problem. Point-in-time capture by design is the only way to close them.

Why Capture Is a DI Function, Not a Graph Function

A context graph is optimized for the read path. Its architecture is designed to answer queries at speed, enforce temporal scope, return applicable context, and explain its reasoning. Every architectural choice in a context graph platform is shaped by that optimization.

Capture requires a different optimization entirely. It requires being embedded in the organizational processes that produce decisions — the approval workflows, the exception-handling chains, the precedent-setting deliberations that happen across the enterprise continuously. A context graph has no view of those processes. It receives artifacts from them. It cannot intercept a decision it does not know is being made.

That design requirement is what makes capture a Decision Intelligence function. DI architecture — as established in the Context Graph Reality Check — is the upstream discipline that governs how decisions are made, recorded, and connected to outcomes. Capture is not a separate function. It is the output of that discipline made concrete. When the DI architecture is in place, capture happens as a natural byproduct of the decision process itself. When it is absent, capture has to be retrofitted — and retrofitted capture produces exactly the partial, inconsistent artifacts that leave a graph queryable but imprecise.

The practical consequence: an organization cannot buy its way into the write path. It has to design its way there. That design work is what DI architecture is — and it is the prerequisite that determines whether any downstream context graph investment delivers on its promise.

What the Market Is Beginning to Elide

Decision traces are beginning to appear in context graph definitions. This is architecturally correct — traces are what make a context graph useful for agent reasoning rather than just rule lookup. The inclusion matters, and it reflects a maturing understanding of what the graph actually needs to ingest.

What that inclusion introduces, quietly, is an ambiguity about production. Including decision traces in the definition of a context graph implicitly suggests that the graph handles them end-to-end. It does not.

The distinction matters for procurement and sequencing. An organization that acquires a context graph expecting it to handle decision trace capture will discover, in production, that the write path was not part of the purchase. The graph will be connected, indexed, and ready to query. What it will be missing is the upstream function that delivers structured traces to ingest. The result is the empty graph problem — expensive infrastructure, nothing worth serving.

Making the write-path distinction explicit now — before the category definition settles — is how the organizational architecture problem stays associated with the discipline that solves it, rather than being absorbed into the infrastructure layer that depends on it.

The Dependency Chain, Stated Plainly

The full sequence from organizational state to agent reasoning runs through five distinct layers. The context graph market conversation lives in layers four and five. The investment case is actually determined in layers one and two.

Each layer depends on the one above it. Layer five — agent reasoning and enforcement — is where the evaluation criteria live and where vendor differentiation is visible. Layers one and two are invisible in vendor evaluations because no vendor sells them. That invisibility is the structural risk. The organizations that extract the most value from context graph infrastructure will be the ones that arrive at it having already established the write path. They will load a graph with structured, queryable, compounding artifacts from day one.

Everyone else will spend the first year trying to understand why the read path is returning imprecise results. The answer will be upstream — in the write path that was not built before the infrastructure was acquired.