When an AI feature gives a confidently wrong answer in production, the instinct of a good engineering org is to fix the system properly — which usually gets proposed as "we should build a company knowledge graph." Resist that instinct for one meeting. Top-down knowledge-graph and master-data projects are where roadmaps go to die: eighteen months of ontology debates, a platform nobody adopts, and the original broken feature still broken. The faster path to a governed ai context layer is to never charter it as a project. Instrument the one feature that is failing, make its context dependencies explicit — source of truth, owner, permissions, provenance — fix it, and let the graph accrete as the union of context contracts you have actually solved.
So the decision in front of you as CTO is not "should we build a knowledge graph." It is "how do I get a governed context layer without funding a moonshot that ships nothing for a year." The answer is emergent, not top-down: the context graph is a byproduct of fixing real retrieval failures one at a time, and you name the architecture last — when it describes something already running in production.
This is the engineering-leadership companion to AI Context in Live Operations, which covered which fields must stay live at request time. This post is about the architecture underneath: how to build the context map those live fields hang on without boiling the ocean.
Key Takeaways
- A company context graph is a structured map of operational truth — which system of record answers which question, who owns it, who may read it, and what proves it. The graph is valuable; the upfront ontology project is not.
- The top-down version fails for the same reason MDM and enterprise knowledge-graph megaprojects fail: you are asked to model the whole business before shipping anything, so nothing ships.
- Make it emergent. Each failing AI feature gets a context contract — source of truth, ownership, permissions, provenance — and the graph is the accumulation of contracts you have shipped.
- The rollout sequence is: instrument one failing feature, fix it via its context contract, let a second team reuse the entity model, then name the pattern. The label "context graph" should be a description of running infrastructure, not a pitch for a budget line.
What this post covers
After reading, you will be able to take one failing AI feature and write its context contract — source of truth, ownership, permissions, provenance — which both fixes the feature and becomes the first node of a context graph you never had to charter as a project.
- Why the top-down knowledge-graph project is the wrong first move
- What a company context graph actually is, at the architecture level
- The four properties of a context contract
- A worked example: instrumenting one failing AI feature
- The accretion sequence that avoids boiling the ocean
- Where a governed retrieval layer fits, and the build-vs-buy call
New to treating context as an explicit layer? Start with AI Context: The Missing Layer Between a Model and a Useful Answer, then come back for the architecture.
Why the top-down knowledge-graph project is the wrong first move
Every engineering leader has either run or inherited a project that began "we just need one canonical model of our data." Master data management, the enterprise knowledge graph, the universal customer schema. The pattern is consistent: the modeling work expands to fill all available time, stakeholders litigate the ontology, and the deliverable is perpetually one quarter away. Meanwhile the concrete problem that justified the project stays unsolved.
A company-context-graph initiative chartered the same way fails the same way. The trap is the sequencing. A top-down graph asks you to model the whole business before you have shipped value, which means you are spending political capital and engineering time against an abstraction the rest of the org cannot see or use. The first demo is months out. By then the sponsor has moved on.
The reframe is to invert the dependency. You do not need a complete model to fix a broken feature — you need the context contract for that feature's questions. So solve the feature. The model accretes underneath as a side effect, and every increment is backed by a shipped fix rather than a slide. This is the difference between an architecture that earns its way in and a platform that has to be sold.
What a company context graph actually is
The architecture view. A company context graph is the materialized map of which system of record is authoritative for which entity, how those entities relate, and what access and provenance rules ride along. It overlaps with a classic knowledge graph, but the engineering goal is narrower and more useful: make ai context resolvable — given a query, return the authoritative, current, permission-checked context with provenance attached, deterministically. It is the concrete output of context engineering: a discipline where every answer traces to an owned, access-controlled, timestamped source rather than to whatever chunk happened to embed nearest.
Why retrieval needs it. Vector retrieval optimizes for semantic proximity, not authority. Point a model at a pile of data silos and it returns the nearest-looking passage — which is frequently a stale wiki copy, a superseded contract draft, or a doc the requester should not see. The model has no concept of "system of record" or "who owns this" or "is this person allowed." The context graph is exactly the layer that encodes those facts so retrieval can honor them. Without it, you are shipping confident retrieval over an ungoverned corpus and hoping the nearest match is also the correct, current, and authorized one.
The senior engineer on your team already holds a mental version of this graph — they know the contract system is truth and the wiki is a cache, they know which fields are sensitive, they know what artifact proves a claim. The work is making that tacit model explicit and machine-readable so software can walk it too.
The four properties of a context contract
You do not start by modeling the company. You start by writing the context contract for one feature's questions. Four properties, and this is the unit the graph accretes from.
1. Source of truth — which system is authoritative? For each question the feature answers, name the single system of record, not the convenient cache. "The contract service holds the terms; the wiki is a derived copy." Most retrieval failures are an authority error: the system answered from an embedded copy instead of the source. Binding each answer to one single source of truth is the highest-leverage fix.
2. Ownership — who is accountable for correctness? Every source needs a named owner who defines "correct" and is on the hook when the record drifts. Unowned sources are how staleness survives in a distributed system: every service assumes another one reconciles it, and none does. Ownership is a property of the data contract, not an org-chart afterthought.
3. Permissions — who may read this, under what conditions? Encode the access rule with the source so retrieval can enforce it per request. This is the property teams skip and the one that turns a helpful assistant into a data-exposure incident — semantic search is permission-blind by default, so if access is not in the contract, it is not enforced at retrieval time.
4. Provenance — what proves the answer? Attach the artifact a skeptical reviewer (or auditor) would accept: the signed contract, the billing line, the approval event with a timestamp. Provenance is what makes retrieval testable — the same query returns the same context, each piece carrying its source and time — and it is what makes an incident explainable instead of a guess.
Four properties, one feature. That contract is a node in the context graph. No ontology committee required.
A worked example: instrumenting one failing AI feature
A platform team ships an internal assistant that answers "what was this customer promised in the deal?" so implementation engineers stop pinging sales. It is subtly wrong often enough to lose trust — quoting a discount negotiated away in redlines, or a feature scoped out before signature.
Instrument the one question — what was this customer promised? — and write its context contract. Source of truth: answers were coming from CRM opportunity notes (sales-stage, aspirational); the truth is the signed contract in the contract service. Ownership: nobody owned the CRM notes post-close, so they were never reconciled against the executed terms. Permissions: the contract carries pricing that not every implementation contractor should see. Provenance: the executed contract PDF and its effective date.
The fix is now an engineering task, not a research project: point retrieval at the contract service as the authoritative source, assign the contract record an owner, scope pricing fields by role at retrieval time, and attach the contract as provenance on every answer. The assistant stops quoting dead promises. You did not charter a knowledge graph — you fixed a feature. But you now hold a reusable customer → contract → promise model that the next feature inherits for free.
This is the dominant enterprise-AI failure mode: the answer is not hallucinated, it is retrieved from a stale or unauthoritative source (RAG About It, 2026). Left unaddressed it compounds — Gartner estimates poor data quality costs organizations $12.9 million a year on average.
The accretion sequence that avoids boiling the ocean
The contract is the easy part. Growing the graph without it becoming a megaproject is the architectural discipline. Run it in this order.
| Step |
What you do |
Why this order |
| 1. Pick one failing AI feature |
Choose a feature with a visible correctness problem and a clear owner |
A shipped fix funds the next increment; an ontology slide does not |
| 2. Write its context contract |
Source of truth, ownership, permissions, provenance — for that feature's questions only |
Scoped to a sprint, backed by a real failure |
| 3. Fix and instrument |
Wire retrieval to the authoritative sources; log provenance on every answer |
Correctness becomes observable, not asserted |
| 4. Let a second feature reuse the model |
Wait for a team to inherit the customer/contract/... entities you defined |
Reuse, not mandate, is what makes the graph spread |
| 5. Name the architecture last |
Now call it a company context graph — as documentation of what runs |
The label lands when it describes production, not a proposal |
The discipline is step 5. By the time you write "company context graph" in an architecture doc, it is the name for infrastructure that already fixed three features and is being reused — not a budget request for a model of everything. That is the line between a platform the org pulls toward it and one engineering has to push uphill.
Where a governed retrieval layer fits — and the build-vs-buy call
A context contract on a whiteboard fixes one feature once. To make it durable and enforceable in production, the contract has to become live infrastructure: sources re-indexed when the record of truth changes, permissions evaluated at the moment of retrieval, and provenance — source plus timestamp — attached to every chunk a model receives. That is real engineering: change-data-capture into the index, an authorization model that travels with the data, and deterministic retrieval so the feature you fixed stays fixed.
You can build that layer in-house — it is a known, finite system — but it is also undifferentiated heavy lifting, and it is exactly what Inherent is built to be. Managed ingestion keeps each contracted source current instead of drifting into a stale embedding. Deterministic retrieval means the same query over the same sources returns the same authoritative context every time. And because every chunk carries its source, its access rules, and an ingestion timestamp, the four properties of your context contract are enforced on every answer rather than re-litigated per feature. The whiteboard contract becomes a context graph the model actually walks.
Whichever way the build-vs-buy call goes, the introduction is the same: instrument a failing feature first, and let the infrastructure earn its name.
The next step
Pick one AI feature that keeps returning a subtly wrong answer in production. Write four lines for the single most important question it answers: source of truth, owner, permissions, provenance. You will almost certainly find the feature is retrieving from a convenient copy rather than the authoritative system of record. That gap is your first context-graph node — and closing it is a shipped correctness fix, not a research charter.
Write those four lines for one feature today. Then DM Flow on X @human_in_loop with which property was emptiest — source of truth, ownership, permissions, or provenance. That empty property is usually where the whole retrieval stack is weakest.
This is Day 29 of the AI readiness series, which began with What Is AI in Business, Really?. For the strategy view of shaping context, see Context Engineering for CEO Strategy; for the practical first pass, see How to Organize Company Context for AI.
