A knowledge graph is a model of connected entities: things and their typed relationships, built to represent and retrieve what an organization knows. A context graph extends it with live operational state, first-class time, and policy and decision links, and operates inside a Context Engine that reasons over situations and executes governed actions.
Context vs knowledge graph: same shape, different job #
Architects who invested in a knowledge graph, for search, for data integration, for a 360-degree customer view, are right to ask the context vs knowledge graph question sharply. Both are graphs. Both model entities and typed relationships. Both promise to connect the enterprise. Vendors blur the terms freely. The distinction is nonetheless real, and it is easiest to state as a difference of job: a knowledge graph is built so the organization can find and relate what it knows; a context graph is built so software can decide and act on specific situations.
That difference of job produces differences of content. Decisions need things representation does not: what is true right now, not just what is generally the case; what was known at the moment a past decision was taken; which policy applies and who is permitted to act; and what was decided before, with what outcome. A context graph carries all four as first-class citizens. Figure 1 shows the relationship as an overlay: the knowledge graph is the inner foundation, and the context graph is the same foundation extended outward.
What a knowledge graph does well #
Give the knowledge graph its full due, because it solved hard problems and its craft transfers directly. A well-built knowledge graph establishes shared identity, one node per real-world thing, and shared semantics, an ontology that makes relationships typed and queryable. On that foundation, enterprises built entity search, research and discovery tools, fraud-ring detection, recommendation, and integration layers that finally connected customer views across silos. Grounding language models is a newer strength: a model that can traverse a curated graph hallucinates less than one browsing raw documents.
Its classic limits mirror its design center. Most knowledge graphs are curated representations of relatively stable knowledge: refreshed on pipelines, weak on volatile operational state, and typically silent about time beyond versioning. They rarely model policy as anything more than access control on the graph itself. And they have no native concept of a decision: nothing in the graph records that on this date, with this information, under this rule, the organization chose this action and got this outcome. None of this is failure; it is scope. The same scope boundary appears in Context vs Data one level down the stack.
The three extensions that make a context graph #
Live state. A context graph is connected to operational systems, not just curated sources, and tracks freshness per fact. The node for a cell site carries its current alarm state; the node for an engineer carries today's availability; the node for an invoice carries its dispute status as of minutes ago. The Context Graph Engine maintains this continuously, which is what elevates the graph into an Enterprise Digital Twin rather than a snapshot.
First-class time. Decisions are audited in the past tense, so the graph must answer as-of questions: not only what is true now, but what was known at 14:32 on the day the credit was approved. Bitemporal treatment of facts, when something was true and when the organization knew it, is the difference between an audit trail and archaeology.
Policy and decision links. Rules, thresholds, and permissions become graph citizens connected to the entities they govern, which lets the Decision Layer apply them in traversal and the Context Harness enforce them at the moment of use. Every decision taken becomes a node linked to its context and its outcome: decision memory, the substrate on which the Understand-Decide-Execute loop learns.
Feature comparison #
| Feature | Knowledge graph | Context graph |
|---|---|---|
| Core content | Entities and typed relationships | Entities, relationships, live state, time, policy, decisions |
| Primary job | Represent and retrieve knowledge | Supply decision-grade context for action |
| Freshness | Pipeline refresh; often batch | Continuous, with freshness tracked per fact |
| Time model | Versioning at best | Bitemporal: current state and as-of reconstruction |
| Policy | Access control on the graph | Policy in the model, enforced at decision time by the Context Harness |
| Decisions | Not represented | First-class nodes with context and outcome (decision memory) |
| Surrounding system | Query endpoints, search, APIs | Decision Layer, Execution Grid, Context Harness: a full Context Engine |
| Typical consumers | Search, analytics, integration, RAG grounding | AI agents, autonomous workflows, decision support |
| Measure of success | Coverage, query relevance | Decision quality, cycle time, straight-through rate, auditability |
Read the table as an upgrade path rather than a rivalry. An existing knowledge graph contributes exactly the hardest-won assets, identity and ontology, and the context graph builds outward from them. The reverse is not true: starting a context program by spending two years on a perfect enterprise ontology repeats the classic knowledge-graph mistake with new vocabulary. Start from one decision and let the ontology grow from what decisions demand.
The difference in three industries #
Banking. The knowledge graph links clients, accounts, and beneficial owners, and it powers investigations well. The context graph adds live exposure, covenant test dates, sanctions-list state, and lending policy, so when a limit request arrives, the Decision Layer can approve within policy in minutes and record exactly what was known. Investigation is representation; approval is operation.
Manufacturing. The knowledge graph connects parts, suppliers, and bills of material, useful for impact analysis. The context graph adds shipment positions, plant status, contractual penalties, and re-sourcing policy, so a force majeure notice triggers a governed re-plan executed across procurement systems, not just a well-informed meeting.
Pharmaceuticals. The knowledge graph relates compounds, trials, sites, and publications for research discovery. The context graph adds enrollment state, protocol amendments in force, site capacity, and regulatory constraints, letting a trial-operations engine rebalance recruitment across sites under policy, with every reallocation remembered as a decision.
A realistic enterprise scenario #
A global insurer built a knowledge graph three years ago: customers, policies, brokers, claims, and legal entities, painstakingly resolved. It powers entity search and fraud-ring analytics, and the team is proud of it. Now the agentic program wants to automate mid-band claims decisions, and the first design review exposes the gaps: the graph does not know a claim's current handling state, cannot reconstruct what was known when a past claim was settled, and carries no representation of settlement authority limits.
Understand. Rather than rebuilding, the team extends: the Context Graph Engine connects the existing graph to the claims platform for live state, adds bitemporal fact handling, and models settlement authority and escalation policy as graph citizens. The knowledge graph becomes the core of a claims-domain Enterprise Digital Twin in one quarter, not three years.
Decide. The Decision Layer runs mid-band claims through governed reasoning: options scored with evidence from the twin, authority limits applied from the model, escalation where the Harness detects fraud-ring proximity, the old graph's specialty, now feeding decisions.
Execute. The Execution Grid settles or routes within the existing claims workflow and writes each decision back as memory. Illustratively, teams extending an existing knowledge graph this way report reaching a working decision loop in one-third to one-half the time of a greenfield build; treat that as a directional range.
Common mistakes to avoid #
- Rebranding without extending: calling the knowledge graph a context graph while state, time, and policy remain absent changes slideware, not decisions.
- Discarding the knowledge graph: throwing away resolved identity and ontology to start fresh wastes the two hardest assets a context graph needs.
- Ontology-first sequencing: perfecting the enterprise schema before shipping a decision is how graph programs of both kinds have historically stalled.
- Ignoring time: a context graph without as-of reconstruction cannot support audit, and governance will treat it accordingly.
- Keeping policy outside: if rules live only in application code, every agent enforces them differently and the Harness has nothing to hold.
- Graph without engine: a context graph queried by ad hoc scripts is a fresher knowledge graph. Value arrives with the Decision Layer and Execution Grid around it.
An architect's decision path #
If you have a knowledge graph, audit it against the three extensions: live state, first-class time, policy and decision links. Whatever passes stays; whatever is missing defines the extension backlog, sequenced by one target decision. If you have no graph, do not build a knowledge graph first and a context graph later; build the context graph for one domain and let representation grow from operation. Either way, insist on the engine: the graph earns its budget when the Understand-Decide-Execute loop runs on it under the Context Harness.
Related reading in the Fundamentals cluster: Context vs Vector Database for the retrieval-stack comparison, Context vs RAG: Beyond Retrieval for the agent-grounding view, and The Enterprise Context Gap Explained for the problem both graphs are ultimately aimed at.
How OpenKnowra approaches this #
The comparison above is category education and applies to any stack. OpenKnowra's position is pragmatic: the Context Graph Engine treats an existing knowledge graph as a first-class source, preserving its identity and ontology while adding live state, bitemporal time, and policy, and raising the result into the Enterprise Digital Twin. The Decision Layer, Execution Grid, and Context Harness then supply the engine most graph programs never had, so the graph investment finally converts into governed, executed decisions.
If you run a knowledge graph today, the fastest evaluation is an extension audit: bring the graph and one decision you want automated, and we will map the gap to a working Understand-Decide-Execute loop on your data.