A context graph is a model of who and what exists in an organization, how those things relate, what happened between them over time, and which outcomes followed. It gives an AI system more than documents to retrieve. It provides entities, relationships, identity, permissions, state changes, event sequences, and reusable evidence about how work actually moves.
The term is useful because enterprise AI often fails between the answer and the outcome. A search engine can find the incident runbook. A knowledge graph can connect the incident to a service and its owner. A context graph can also represent that a monitor fired, an engineer acknowledged it, a rollback failed, a database setting changed, the service recovered, and the change was later approved as the new standard path.
That does not make a context graph an automatic model of human intent. Events show what happened; they do not always reveal why. A reliable implementation keeps observed facts, inferred relationships, predicted next steps, and approved procedures distinct.
The short answer
A practical context graph combines five kinds of context:
Entities: people, teams, customers, products, projects, services, documents, tickets, systems, and agents.
Relationships: owns, works on, applies to, depends on, approved, mentioned, supersedes, caused, and resolved.
Temporal events: created, viewed, edited, assigned, escalated, approved, deployed, failed, recovered, and closed—with timestamps and source evidence.
Policy context: identity, permissions, sensitivity, retention, valid-time boundaries, and action authority.
Outcome signals: success, correction, approval, intervention, latency, cost, user feedback, and downstream state.
The graph becomes useful when a system can retrieve a bounded subgraph for one user and task, assemble it with primary evidence, distinguish observation from inference, and turn the result into a reviewable answer or controlled action.
Context graph vs knowledge graph
The categories overlap, but their center of gravity differs.
Model | Primary question | Typical nodes and edges | Time | Main use |
|---|---|---|---|---|
Document index | Which text matches? | chunks, fields, links | freshness metadata | search and retrieval |
Knowledge graph | What exists and how is it related? | entities and semantic relationships | often current-state or versioned | discovery, reasoning, integration |
Event log | What happened and when? | ordered events and state transitions | first-class | audit, analytics, process mining |
Workflow definition | What should happen? | steps, conditions, roles, actions | execution state | repeatable automation |
Context graph | What exists, what happened, for whom, under which policy, and with what result? | entities, relationships, events, evidence, permissions, outcomes | first-class | grounded assistance and adaptive work |
A context graph is therefore not merely a knowledge graph with a timestamp column. It treats actions and state transitions as first-class objects, preserves the source and authorization context of those observations, and connects them to outcomes that may influence later retrieval or planning.
It is also not a replacement for workflows. A learned pattern describes how work has happened; a workflow defines an approved path. High-risk actions should follow explicit policy even when historical traces suggest that employees often took a shortcut.
A minimum viable context model
Entity identity
Every entity needs a stable ID independent of its display name. The same person may appear under different identifiers in email, chat, CRM, code, and ticketing systems. Projects, customers, services, and products also need reconciliation rules.
Keep source-native IDs and canonical links. Identity resolution should record confidence and provenance rather than silently merging similar names. A wrong merge can expose restricted information or attribute an action to the wrong person.
Typed relationships
Relationships need direction, type, source, validity, and sometimes confidence. “Alice owns Service X” is different from “Alice edited a document about Service X.” One may be an authoritative assignment; the other is an observed interaction.
Useful properties include:
relationship type and direction;
asserted-by source or derived-by model;
observed, inferred, or approved status;
valid-from and valid-to timestamps;
permission boundary and sensitivity;
confidence and supporting evidence;
superseded or disputed state.
Event envelopes
An event should answer: who or what acted, what action occurred, which object changed, when it happened, where it came from, what state existed before and after, who may use the event, and what evidence supports it.
A useful envelope contains:
event ID and source event ID;
actor identity and actor type—human, service, or agent;
action type and target entity;
event time and ingestion time;
source application and canonical URL;
before/after state or a bounded change set;
workspace, customer, project, or process scope;
source ACL, classification, retention, and residency;
correlation, causation, session, and workflow IDs where available;
evidence pointer and transformation lineage;
outcome and review status when later known.
Do not infer causality from sequence alone. “Ticket updated after meeting” is observed ordering. “Meeting caused update” is a claim that needs explicit linkage or an inference label.
Policy and authority
The graph must know not only what is connected but what the current user and agent may retrieve or do. Authorization belongs in candidate generation, traversal, reranking, context assembly, generation, citations, memory, export, and action execution.
Policy can also constrain interpretation. A draft procedure is evidence that someone considered a method; it is not an approved playbook. An expired account relationship should not personalize current results. A past manager may explain an old decision but must not inherit present approval authority.
Outcomes
Without outcomes, a context graph risks becoming an expensive activity map. Capture whether a path completed, required intervention, was approved, was reverted, caused an incident, satisfied the requester, or changed the intended system state.
Outcome labels should be specific to the task. A fast sales handoff and a safe security exception do not share the same definition of success.
Reference architecture
1. Observe source systems
Connect applications where objects and work events originate: documents, chat, email, calendars, tickets, CRM, code, deployment systems, support platforms, dashboards, and structured databases.
Collect only the object types and events needed for defined use cases. Preserve deletes and permission changes. Broad surveillance without a task, consent model, retention policy, and access boundary creates risk faster than value.
2. Normalize without flattening
Map source objects to a shared schema while retaining source-specific meaning. A Jira transition, CRM stage change, document approval, and deployment event can share a generic state_changed class but should keep their native fields and semantics.
3. Resolve identities and entities
Reconcile people, teams, projects, products, services, customers, and agents across sources. Use deterministic keys where possible. Place probabilistic matches in a reviewable state and retain the evidence used to create them.
4. Build structural and temporal layers
Maintain a structural graph for relatively durable entities and relationships, plus a temporal event layer for actions and state changes. Connect events to the entities they affected, the evidence that describes them, and the policies governing reuse.
The physical storage does not have to be one graph database. A practical system may combine a search index, vector store, relational or event store, graph projections, object storage, and caches. “Context graph” describes the logical contract more than one database product.
5. Derive patterns carefully
Sequences can reveal common paths, delays, handoffs, exceptions, and candidate next steps. Keep each derived pattern tied to its population, time range, source coverage, confidence, and validation state.
A pattern observed in the enterprise sales team may not apply to self-serve customers. A path that appears efficient may omit work performed in an unconnected system. Subject-matter review is essential before turning traces into a recommended playbook.
6. Retrieve a task-specific subgraph
At runtime, begin with the authorized user, task, and seed entities. Retrieve relevant objects, neighboring relationships, recent events, prior analogous cases, applicable policy, and primary evidence. Apply time, region, customer, product, status, and sensitivity filters.
Avoid sending a large graph dump to a model. Assemble a compact context package with explicit claims, source links, temporal order, conflicts, gaps, and allowed actions.
7. Answer, propose, or act
The system can use the context package to answer a question, prepare a brief, recommend a next step, or propose an action. Separate read, propose, approve, and execute. Every external action needs current authorization, validation, idempotency, rollback, and audit evidence.
8. Record the result
Agent tool calls, human corrections, approvals, outcomes, and downstream state changes become new traces. Do not treat every successful completion as proof that the chosen path was optimal. Evaluate correctness, safety, completeness, cost, and user outcome before reinforcing a pattern.
Three practical use cases
Incident response
Connect services, dependencies, owners, alerts, tickets, chat, deployments, runbooks, and postmortems. The graph can retrieve what changed before similar incidents, who resolved them, which steps were approved, and which workaround later became obsolete.
The output should show current service ownership and runbook authority separately from historical behavior. A previous emergency action is evidence, not automatic permission to repeat it.
Customer onboarding
Connect account, contract, promised capabilities, security review, implementation tasks, meetings, support issues, owners, and milestones. The graph can explain the current state, identify the blocking dependency, compare similar deployments, and draft the next coordinated plan.
Customer isolation is critical. Similarity across accounts must not leak customer-specific content, identifiers, contract terms, or private outcomes.
Product delivery
Connect research, decisions, specifications, roadmap items, design assets, code, releases, feedback, and incidents. The graph can reconstruct why a decision changed, find affected work, and prepare an evidence-linked launch or rollback brief.
Preserve decision authority. High activity around an idea does not make it approved roadmap scope.
Security, privacy, and governance
Purpose limitation
State the use case before collecting activity. Data captured to improve search should not automatically become employee performance scoring or autonomous workflow training.
Data minimization
Capture the smallest event and content set that supports the task. Consider storing references or derived, access-controlled features instead of raw message bodies when the body is not required.
Permission-aware traversal
Filter nodes, edges, event attributes, aggregates, and derived patterns. Even a count or relationship can reveal a restricted project, customer, or investigation.
Temporal correctness
Distinguish event time, ingestion time, and validity time. Late events and retroactive corrections must not rewrite history invisibly. Answers should state the relevant “as of” boundary.
Inference transparency
Label observed, asserted, inferred, predicted, and approved information. Expose confidence and evidence for material inferences. Allow owners to dispute or correct derived relationships.
Retention and deletion
Define how source deletion, legal hold, retention, employee departure, customer termination, and residency affect events, embeddings, graph projections, caches, memories, and generated artifacts.
Human and agent identity
Record whether a human, service, or agent performed each action. Agent activity must have a principal, scopes, tool version, inputs, outputs, approval evidence, and outcome.
How to evaluate a context graph
Build a judged set of questions and tasks that require relationships and time—not only document lookup.
Area | Test | Measure |
|---|---|---|
Entity quality | Are identities correctly reconciled? | precision, unresolved rate, bad-merge rate |
Event fidelity | Are required state changes present and ordered? | coverage, latency, duplicate and late-event rate |
Relationship quality | Are edges supported and correctly typed? | precision, provenance coverage, dispute rate |
Authorization | Can any role observe forbidden graph context? | violations, revocation latency, inference leakage |
Temporal reasoning | Does the answer use the right time boundary? | valid-time accuracy, stale-state rate |
Pattern validity | Do learned paths generalize to the intended scope? | expert acceptance, intervention, exception rate |
Outcome quality | Does the recommendation improve work safely? | completion, correction, rollback, cost, latency |
Explainability | Can a user inspect the supporting trace? | evidence coverage, openable source rate |
Include deactivated users, renamed groups, merged accounts, deleted tickets, backfilled events, conflicting timestamps, hidden projects, customer isolation, incomplete source coverage, process exceptions, human corrections, and valid no-answer cases.
Common failure modes
Calling any enterprise graph a context graph
A directory of people, documents, and links provides structure. It does not necessarily model event sequences, policy, outcomes, or how work changes.
Confusing correlation with causation
Repeated order can suggest a pattern, not prove why the path worked. Preserve alternative explanations and require validation for high-impact claims.
Learning the current mess
Historical traces contain shortcuts, bias, policy violations, duplicate work, and accidental success. “Common” is not the same as “approved.”
Ignoring missing systems
An apparent process may omit phone calls, private tools, external partners, or uncaptured judgment. Report coverage and gaps with every derived pattern.
Building a universal supergraph first
Start with one workflow and the entities, events, and policies it requires. A graph without a bounded retrieval and outcome loop becomes a costly integration project.
Treating personalization as permission
Knowing that a person frequently works with a project does not grant access to it. Authorization must remain explicit and current.
Reinforcing agent traces without evaluation
A completed run may be inefficient, unsafe, or corrected later. Score outcomes before using traces as future guidance.
A 90-day implementation path
Days 1–30: one task and one event contract
Choose a workflow whose outcome can be observed. Define entities, source systems, event envelope, identity rules, forbidden data, permissions, retention, and success measures. Create representative historical cases and judged questions.
Days 31–60: build and test the bounded graph
Ingest the minimum required objects and events. Resolve identities, preserve ACLs, link primary evidence, and expose temporal queries. Mutate permissions and source state. Validate relationships and traces with domain experts.
Days 61–90: retrieve, propose, and learn safely
Retrieve task-specific subgraphs and generate evidence-linked proposals. Add human approval before actions. Record corrections and outcomes, classify failure causes, and rerun the same cases. Expand only after security, fidelity, and outcome thresholds hold.
Frequently asked questions
What is a context graph?
It is a model that connects enterprise entities and relationships with temporal actions, policy context, source evidence, and outcomes so AI can understand and assist with how work changes over time.
Is a context graph the same as a knowledge graph?
No. A knowledge graph primarily represents entities and semantic relationships. A context graph makes temporal actions, authorization, evidence, and outcomes first-class, often using a knowledge graph as one layer.
Do we need a graph database?
Not necessarily. The logical model can span search, relational, event, graph, vector, and object stores. Choose storage based on retrieval, traversal, scale, latency, governance, and operational requirements.
Can a context graph learn business processes automatically?
It can identify recurring sequences and candidate patterns from traces. Those patterns still require coverage analysis, scope, confidence, policy checks, and expert validation before becoming recommended or automated procedures.
What data should we collect first?
Collect only the entities, state changes, evidence, permissions, and outcomes required for one valuable workflow. Start with reliable source IDs and explicit events rather than attempting universal activity capture.
What is the biggest security risk?
Cross-source inference leakage: a node, edge, count, recommendation, or generated answer can reveal restricted information even when the underlying document is not shown. Authorization must apply throughout retrieval and reasoning.
Sources
Where Dokki fits
Dokki gives a context graph a practical surface for work: documents, tables, decisions, people, and agent outputs remain connected to their provenance and review state. Begin with a few high-value relationships—owner, source, approval, dependency, and outcome—rather than trying to model the whole company.
_Last verified: July 21, 2026._