Open Data Infrastructure
Context Graph vs Knowledge Graph for AI-Ready Data
Knowledge graphs describe entities and relationships. Context graphs describe the operational evidence an agent needs before it acts.
A knowledge graph can tell an agent that a customer owns an account. A context graph should tell the agent whether it is allowed to use that fact right now.
The practical problem
AI-ready data discussions often collapse every connected-data idea into "knowledge graph." That loses an important distinction. Entity meaning is not the same as operational readiness.
A knowledge graph is useful for modeling entities, relationships, classes, and facts. A context graph, in the ODI sense, connects business meaning to the infrastructure evidence an agent needs: lineage, freshness, permissions, quality, provenance, model contracts, and usage constraints.
Core idea: knowledge graphs help agents know what things mean. Context graphs help agents know whether, how, and why they can use those things.
The ODI boundary
The boundary is actionability. A graph of entities can improve discovery and reasoning, but an agent that acts on enterprise data needs more than entity relationships. It needs governed context.
That context includes source systems, table snapshots, data products, owners, policies, quality signals, lineage events, and access decisions. Standards such as RDF and PROV help describe meaning and provenance. Lineage systems and metadata platforms help capture operational evidence. ODI connects those pieces into an architecture an agent can safely use.
Patterns that work
Use a knowledge graph for stable business meaning: customers, products, accounts, suppliers, regions, contracts, and the relationships among them. Keep it curated. Do not turn every log event into an ontology argument.
Use a context graph for runtime evidence: which table version is current, which policy applies, whether the dataset is fresh, which upstream job produced the value, which owner is responsible, and which downstream action is allowed.
Connect the two through identifiers and contracts. The customer entity should link to governed tables, approved metrics, lineage paths, and policy status. That lets the agent move from meaning to evidence without guessing from table names.
Failure modes
The first failure is ontology theater. Teams build a beautiful model of the business and never connect it to the data paths that agents actually query.
The second failure is metadata soup. Everything becomes a node, every node gets three labels, and nobody can answer whether the agent is allowed to use a field in production.
The third failure is stale context. If the graph does not reflect current policy, freshness, or lineage, it becomes a confident source of old truth.
Questions to ask
- Which graph captures business meaning, and which graph captures operational evidence?
- Can an agent trace a fact to source, policy, freshness, and owner?
- How are entity identifiers linked to tables, metrics, and lineage?
- Which context facts are updated automatically, and which require human curation?
- Can the graph explain a denied action as clearly as an allowed one?
For deeper AI context work, read Context Graphs for AI, Knowledge Graphs and ODI, and AI-Ready Context Data for Agents.
Sources to start with
Start with the primary docs. They are the contracts you can test against, not commentary about the contracts.