Context Graphs and Organizational Judgment

Reading time ~12 min · Quiz at the end

A sales rep at a mid-market SaaS company approves a 20% discount on a renewal. Company policy caps discretionary discounts at 15%. Nothing crashes. No alert fires. Finance notices the variance three weeks later during quarterly reconciliation and escalates it as a compliance exception.

Here is what actually happened, and it took a human two hours of Slack archaeology to reconstruct it. The account in question is a strategic renewal — a logo the company uses in every board deck. Four months earlier, a competitor undercut the renewal quote by 30%. The VP of Sales personally approved a 20% discount to hold the account, on the explicit condition that it was a one-time exception tied to a documented competitive threat, not a new floor. The rep who processed this quarter's renewal was new, inherited the account, saw the prior invoice at 20% off list, and assumed that was the negotiated rate going forward. No one told her otherwise, because the person who approved the exception left the rationale in a Slack thread and a verbal aside in a QBR, not in any system a new hire would ever see.

This is the scenario this lesson is built around, and it is worth sitting with because it is not a data problem. Every fact involved — the 15% policy, the prior invoice at 20%, the VP's approval — is written down somewhere and perfectly retrievable. What is missing is not a fact. It is the structure connecting the facts: that the 20% was an exception, not a rule; that it was scoped to a specific justification; that the justification had a shelf life; that renewing it required going back to the same approver, not defaulting to the exception because it appears in the account's history. That structure is what we mean by organizational judgment, and it is the layer above per-call context engineering that this lesson addresses.

Why retrieval alone fails for judgment

If you build a rep-facing agent to answer "what discount can I offer?" and you wire it to a vector store over your policy documents and deal history, here is what it retrieves for this account: the 15% policy document, and possibly the prior invoice showing 20%. A similarity search over unstructured text has no native way to represent "this fact is an exception to that fact, granted by this person, for this reason, with this expiration." It can retrieve both documents. It cannot tell you which one governs, because governance is not a property of either document in isolation — it is a property of the relationship between them.

This is the general failure mode of retrieval-augmented context when the task is judgment rather than lookup. Retrieval is excellent at "what does the policy say" and "what happened last time." It is structurally unable to answer "what applies here, and why" when the answer depends on precedent, exception, and chained justification. You can paper over this with more elaborate prompting — stuff every retrieved chunk into context and ask the model to reason about which one wins — but you are asking the model to reconstruct, from unstructured fragments and every single call, a piece of institutional reasoning that a five-year employee holds instantly and for free. That reconstruction is expensive, inconsistent across calls, and silently wrong exactly when it matters most: the exception case, not the routine one.

A schema for organizational judgment

You do not need a research-grade knowledge representation system to start capturing this. You need a small, deliberately opinionated graph schema with enough node and edge types to represent decisions, the policies they relate to, the precedents they set or follow, the people who made them, and what happened as a result. Here is a minimal schema that covers the discount scenario and generalizes to most enterprise judgment-capture problems — claims adjudication, underwriting exceptions, field service escalations, content approval overrides.

// Node types
Decision   { id, description, timestamp, status }
Policy     { id, name, text_ref, effective_date }
Precedent  { id, description, scope, expires_at }
Actor      { id, name, role, authority_level }
Outcome    { id, description, observed_at, metric_ref }

// Edge types
(Decision)  -[:JUSTIFIED_BY]->   (Precedent | Outcome)
(Decision)  -[:EXCEPTION_TO]->   (Policy)
(Decision)  -[:SUPERSEDED_BY]->  (Decision)
(Decision)  -[:DECIDED_BY]->     (Actor)
(Decision)  -[:RESULTED_IN]->    (Outcome)
(Precedent) -[:EXCEPTION_TO]->   (Policy)
(Precedent) -[:DECIDED_BY]->     (Actor)

// The discount case, instantiated
Decision(d1: "Approve 20% discount, Acme Corp renewal Q1")
  -[:EXCEPTION_TO]-> Policy(p1: "Discretionary discount cap 15%")
  -[:JUSTIFIED_BY]-> Outcome(o1: "Competitor quote 30% below list, evidenced in RFP doc")
  -[:DECIDED_BY]-> Actor(a1: "VP Sales, authority_level: exception-approval")
  -[:RESULTED_IN]-> Outcome(o2: "Renewal retained, ARR $420k")

Precedent(pr1: "20% exception is scoped to competitive-threat justification, not a new floor")
  -[:EXCEPTION_TO]-> Policy(p1)
  -[:DECIDED_BY]-> Actor(a1)
  expires_at: "re-approval required each renewal cycle"

Notice what this buys you that the flat documents never could. The precedent node explicitly encodes its own scope and expiration — it is not a fact you infer from a Slack thread, it is a first-class object with a lifecycle. The EXCEPTION_TO edge means a query for "what discount applies to Acme's renewal" doesn't just surface the 15% policy; it surfaces the policy and the exception and the condition under which the exception holds, in one traversal. If the new rep's agent had walked this graph instead of searching a vector store, the answer would have been: "Policy caps discounts at 15%. There is a documented exception at 20% for this account, approved by [VP], scoped to a competitive-threat justification from Q1. That justification has not been re-verified for this renewal cycle — confirm the competitive threat still applies, or default to policy."

That is not a smarter model. It is the same model, given a data structure that carries reasoning instead of just records.

How the graph feeds context assembly at inference time

The context graph does not replace your existing context engineering — it sits above it as a second retrieval pass with a different query shape. A typical assembly pipeline for the discount-agent scenario looks like this: the rep's query ("what can I offer Acme?") triggers a policy lookup (vector or keyword, fine either way) to find candidate governing policies; in parallel, it triggers a graph traversal from the account entity outward — one or two hops — to find any Decision or Precedent nodes connected to that account or to the policies just retrieved. The graph traversal result is small (a handful of nodes, not a document dump) and it is structured, so it can be rendered into context as a compact, labeled block: "Standing policy: X. Active exception: Y, scoped to Z, approved by W, last verified [date]." That block goes into the prompt alongside the retrieved policy text, and the model's job shifts from "infer the relationship between these two documents" to "apply this already-resolved relationship to the current case." You are not asking the model to do the judgment work at inference time. You did the judgment work once, when you curated the graph, and now you are handing the model the resolved answer as context.

This has a direct implication for where errors show up. If the graph is wrong or stale, the agent will confidently apply an outdated exception — which is a curation failure, not a model failure, and it's fixable by the same people who caused it: whoever owns the graph. If the graph is missing an edge (say, no one ever recorded that the exception expired), the agent falls back to the flat policy, which is the safe default and exactly what you want a judgment gap to resolve to.

Building it: start with one team, one quarter

The instinct with anything called a "knowledge graph" is to scope it as an enterprise-wide initiative — buy a graph database, appoint an ontology committee, model every department's decision-making before writing a single node. This fails for the same reason every top-down enterprise knowledge management effort has failed for thirty years: the schema ends up either so generic it captures nothing useful, or so elaborate that no one populates it.

Start absurdly small instead. Pick one team — sales operations, claims adjudication, one field-service region — and capture their decision log for a single quarter. Concretely: every time someone makes a judgment call that deviates from documented policy (approves an exception, overrides a default, escalates past the normal path), write it down as a Decision node with its justification, its approver, and, if it's meant to set precedent, a Precedent node with an explicit scope and expiration. Do this by hand, in a spreadsheet if you have to, before you write a line of graph database code. The schema above is a starting point, not a mandate — you will discover your organization needs a sixth node type or a different edge semantics after living with real cases for a few weeks, and that discovery is the point of starting small.

Only after you have twenty or thirty hand-curated decisions that actually reflect how your team reasons should you think about automating capture — and even then, automate the proposal of new nodes and edges, with a human confirming before they're committed. The value of the graph is entirely a function of precision, not coverage. A hundred carefully justified precedent nodes that agents can trust unconditionally beat ten thousand auto-extracted ones that need to be double-checked every time, because the moment an agent (or a person) can't trust the graph, they stop consulting it and you're back to Slack archaeology.

Own the graph, rent everything else

This lesson sits inside a claim made throughout this course: orchestration glue — the code that calls tools, routes between agents, retries failures — is being absorbed into model provider SDKs at a pace that makes it a bad place to invest differentiation. What is not being absorbed, and cannot be, is the specific record of how your organization actually makes decisions: which exceptions you've granted, which precedents you've set, which actors hold which authority, and why. No frontier lab is going to ship you a graph of your own company's judgment calls, because they have no visibility into them — they live in your Slack, your approval emails, your adjusters' heads, your VP's QBR asides. That makes the context graph the closest thing this stack has to a durable, compounding asset. Every well-curated Decision node makes every future related decision faster and more consistent to make — by a human or an agent — and that value doesn't decay when a new model ships, the way a cleverly engineered prompt sometimes does. It compounds when a new employee's first query against the graph surfaces four years of institutional reasoning instead of a policy document and a shrug. Build or buy your orchestration layer freely; the switching cost there is genuinely low, and paying a premium to avoid vendor lock-in on commodity glue is money wasted. The graph is the opposite case. If a vendor offers to host your organizational judgment graph on their infrastructure with their schema, read the contract for what happens to your data on exit, because this is the one layer where "we'll just switch providers later" is not actually true — the graph is the switching cost.