A white paper
A governed knowledge graph for the age of agents: give every artifact a business address, file knowledge as a by-product of shipping, and let people and AI interrogate the organization through one trusted layer.
Enterprises have bought the models. What they cannot buy is their own knowledge in a form a model can use. Most of what an organization knows lives in heads, meetings, and wiki spaces nobody owns, and an AI agent can only reason over what it can retrieve. This is the constraint on enterprise AI value, and it is a data problem, not a model problem.
This paper describes a reference design that fixes it in four moves:
The payoff is the share of meetings, searching, and re-explaining spent moving context between people. In an illustrative model, that is tens of millions of dollars a year at a large enterprise, and it funds the graph many times over. The design is prototyped and proposed, not in production; Section 10 states exactly what exists.
1
Enterprise AI adoption is up and value is flat. Gartner's October 2025 survey found 88% of HR leaders report no significant business value from AI tools, and McKinsey's State of AI 2025 found that while 88% of organizations use AI, only about 6% attribute meaningful EBIT to it. One reason sits underneath all the others: lossy context transfer. Enterprise context lives in heads and meetings, is passed along by voice, and decays with every hop and every departure.
AI makes this worse unless it is fixed. Context locked in a meeting is invisible to an agent, and context scattered across hundreds of Confluence spaces and Jira projects is only marginally better: retrievable by keyword, with no structure, no provenance, and no way to know whether it is current.
The usual answer is "put it in a vector store." That gets a model to a passage. It does not get the model to a relationship: what depends on this capability, which controls test this function, which team owns this service, what was decided about this and why. Those are the questions that inform decisions, and they are graph questions.
The result, in the reference implementation (a large regulated U.S. digital financial services firm), was the familiar pattern: engineers spending afternoons in chat threads to find out which service owns a field; product owners answering the same questions in five channels; security and architecture weighing in months late because nothing told them, at concept time, that a new feature sat inside PCI scope.
2
Five rules shaped the design. Each one closes a specific way knowledge systems fail.
3
Illustrative address:
The spine is the organization's map. Every project files at a coordinate, and the union of projects is the taxonomy. Three properties matter:
The spine is itself a governed, versioned artifact with a steward, normally the business-architecture function. Projects pin a spine version, so the map can move without breaking what was filed against it.
Brownfield reality. No enterprise can hand-author hundreds of PRDs to seed the graph. The build path is: new products start in the model; existing products get stub nodes that backfill over time; an agent reads existing Jira and Confluence to propose functions for each capability, and a human adjudicates the proposals. A partially accurate map with freshness signals beats tribal knowledge with none.
4
A street address does two jobs. It locates a building on a map everyone shares, and it stays the same for everything that happens at that building: the deed, the permits, the utilities, the inspections, the mail. A business address works the same way. The feature Recurring Billing Setup has one canonical address on the spine, and that address is stamped on every artifact that touches the feature, in every repository, in every function of the company.
This is what makes the graph useful rather than just large. Today, the web front end, the mobile app, the API layer, the servicing tier, the back end, and the third-party integration for one feature live in six repositories owned by five teams, and the architecture review, security assessment, risk acceptance, legal review, and change record for the same feature live in five more systems. Nothing joins them except people's memory. With a canonical address, one query returns all of it.
…/Billing/* and sees every merge, decision, and test under it without attending a meeting.The blue floors are repositories, and they are the one layer that is never stale, because the commit is the truth. Source code never enters the knowledge layer. What enters is a code manifest, generated on every merge: what the repository is (components, services), what it exposes (API contracts, events, datasets written), what it consumes (contracts called, events subscribed, datasets read), what it depends on (libraries, platforms, deploy targets), who owns it, and which feature addresses it implements. Most of that is parsed, not interpreted, from artifacts that already exist: OpenAPI and AsyncAPI specs, event schemas, infrastructure-as-code, package manifests, CI pipelines, and CODEOWNERS. No tokens, no inference, re-run on every merge.
One repository's consumes is another repository's exposes. Once every repo in an estate files a manifest, the upstream and downstream graph assembles itself across repositories without anyone drawing it. "What is downstream of validateBillingDate?" stops being an investigation and becomes a traversal, joined to the requirements, controls, and production events at the same address.
parsed facts come from contracts, infrastructure-as-code, manifests, and import graphs and are canon on merge. inferred facts come from an agent reading what a module does; they carry the agent, the commit, and a confidence, and they stay proposals until adjudicated. Inference finds candidates; prescription admits them.None of this works if the address and the metadata are added afterward. Every artifact type has a template, and the template carries the fields the graph needs in machine-readable front-matter: the address, the owner, the review cadence, the classification, the spine and PRD versions, and the provenance of whatever it was derived from. A continuous-integration check rejects any artifact that is missing a required field or names an address that does not exist on the spine. Curation is not a review step after the fact; it is the template doing its job at creation.
| Artifact | Template carries | Gate checks |
|---|---|---|
| PRD / feature spec | address, owner, cadence, status, requirement rows with IDs | address exists; every requirement row has an ID |
| Design / ADR | address, requirement IDs it satisfies, decision, options, status | no design without a requirement; ADR immutable once accepted |
| Code manifest | address(es), owner from CODEOWNERS, exposes, consumes, depends, deploys | generated on merge; every repo in an estate has one |
| Executable test | address, requirement IDs it verifies | no requirement marked done without a passing test |
| Control / runbook / policy | address, owner, cadence, classification, what it tests or governs | cadence set by risk tier; attestation recorded |
| Ticket / change record | address in a required field | no ticket without an address; address resolves on the spine |
An address with no owner is a wiki page with a nicer name. Every node, and every artifact filed at it, carries a named owner, a review cadence, and a last-attested date. Freshness is computed, not asserted: a node is fresh within its cadence, due as the cadence ends, and stale past it. Stale content is served with its flag, never silently. Ownership follows the organization, so when a team changes, the steward reassigns owners at the address and the history stays attached.
5
The knowledge layer indexes every addressed artifact and the relationships among capabilities, features, services, APIs, datasets, controls, tests, incidents, decisions, and owners.
| Tier | What it holds | Lives in | Governance |
|---|---|---|---|
| Personal | An individual's local memory and notes: an architect's scar tissue | Their own workspace | Isolated to the person; informs judgment, never becomes canon |
| Institutional | Architecture standards, NFR baselines, security policy, decisions | The knowledge layer | Lifecycle-governed; "a standard is an answer the graph gives you" |
| Product | The PRD and its prescriptive artifacts: specs, ADRs, executable tests, runbooks | Versioned repository | Merge-request review; consumes the institutional tier and writes decisions back |
This answers the question every enterprise asks and none can answer today: where do the architecture standards live? In the knowledge layer, not on a laptop.
When a merge request is approved and merged, its artifacts ingest as born-structured content: declared spine alignment from front-matter, known provenance from the commit, no inference required. Code ingests the same way, as the generated manifest described in Section 4, never as source. Status digests are machine-generated from the ticketing system and the repository, never hand-written. Knowledge converges because shipping converges it.
declared (from a template), parsed (from a contract, manifest, or infrastructure definition), or inferred (by an agent, pending adjudication).Vector search finds relevant passages. Graph traversal finds relevant relationships. The knowledge layer does both: a question like "what else consumes validateBillingDate?" is a traversal; "what did we decide about billing-date validation?" is a vector hit on a decision record plus a traversal to its neighbors. The graph layer runs on a managed graph database on AWS, with object storage for artifacts and ingestion from the repository, the ticketing system, and the wiki.
The graph is exposed as governed Model Context Protocol tools, so context is pulled into an agent's window rather than pasted. The same tools serve three surfaces: Copilot over the ticketing and wiki tools for the broad workforce; coding agents working in the repository, bootstrapped with a generated context bundle (the constitution, the addressed spec, and the graph neighbors of the capability being built); and a workbench where each project is an isolated workspace filed at a spine coordinate, teams work in a local copy, and merge requests change shared truth.
6
Two things the graph does that a document store cannot. Pick a question to watch traversal answer it, or switch who is asking to see authorization enforced per node while addressability stays intact.
7
| Question today | How it is answered | With the knowledge layer |
|---|---|---|
| Who owns this service? | Ask around; search three wikis | Graph lookup, with the owner's attestation date |
| What depends on this capability? | Meeting with four teams | Traversal; dependencies generated, not negotiated |
| Is this feature in PCI scope? | Security review in month three | Inherited from spine position at concept time |
| What did we decide, and why? | Whoever was in the room | Decision record at an address, with provenance |
| Which controls test this function? | Audit pack assembled by hand | Query; evidence by construction |
| Is this document current? | Guess | Freshness signal; stale nodes flagged |
The addressable cost is the share of meetings, searching, and re-explaining spent moving context between people. An illustrative model: a 30-person project status meeting, three times a week, one hour, 52 weeks, at a $150 fully loaded rate costs about $702,000 a year. Across 200 projects that is roughly $140M for one recurring series alone, before the rest of the ceremony stack.
8
Solved by node-level entitlements and isolation by default. The cost is that the entitlement model must be built before the graph is useful, not after.
It will, if it is treated as a project. Anchor on capabilities, enforce addresses at creation, assign owners and attestation dates, flag staleness automatically, fund the steward. This is governance, not a build.
Authority tiers and ambers. Contradictions become work items for an adjudicator, not silent drift.
Stubs, backfill, agent-proposed functions with human adjudication. No big bang.
The trail is criteria → test → evidence, never "the AI said so." The refusal primitive keeps the single source of truth honest.
Cross-team coordination as a graph view is a design choice; gate cadence is a leadership choice. Tooling can make dependencies visible in seconds. Whether a decision takes an hour or a quarter is org design.
9
Phase 0 (6–8 weeks). Map one bounded domain onto the spine. Assign owners. Baseline the time currently spent on context transfer in that domain.
Phase 1 (12–16 weeks). Stand up the graph for that domain: ingestion on merge, entitlements, freshness. Migrate its PRDs, decision records, and runbooks into addressed artifacts. Expose tools to Copilot and coding agents. Replace status meetings with generated digests. Exit when at least 90% of the domain's nodes are attested, every artifact carries an address, and the risk partner confirms the evidence trail is equal or better.
Phase 2 (months 5–12). Extend to 3–5 domains across at least two lines of business. Productize the ingestion, the tool catalog, and the workbench. Hand the spine to a named steward in business architecture.
Phase 3 (months 13–24). The spine covers all lines of business; portfolio planning, audit packs, and agent context all run on it.
10