What is a knowledge graph?

A knowledge graph represents data as a network of entities (a customer, a plant, a contract, a supplier) connected by explicit relationships (owns, feeds, depends on, is supplied by). Note: this is not Google's "Knowledge Graph" from search results; here the term means the enterprise knowledge graph, the knowledge layer built on your organization's data. Unlike a relational database, where relationships between tables stay implicit and have to be rebuilt every time through complex joins, in a graph the relationship is itself a first-class piece of data, queryable just like the entities it connects. This lets an organization ask questions spanning multiple systems, customer records, plant maintenance, the contracts register, without redoing an integration per question, because the graph already holds them together under an explicit schema, the ontology. That is why it is now considered the most solid layer to build reliable AI applications on, from GraphRAG to agents that need to reason about how the business fits together.

See also: Personal Knowledge Management (PKM) · The method for organizing your own knowledge into a personal network of linked notes: increasingly maintained by an AI agent today.

What it solves

In traditional databases the relationships between data exist but are implicit, scattered across tables and systems. Questions spanning several systems ("which customers are impacted by this plant stopping?", "what is our exposure to this supplier, counting sub-suppliers?") require manual reconstructions that cost days. In a graph the relationship is the data: those questions become one query, and every answer is traceable along the path that produced it.

An enterprise example

A machinery manufacturer keeps its data in three places: the ERP holds the bills of materials, the CRM the end customers, the service system the interventions. The question nobody manages to close is which already installed machine contains a component whose supplier has lost a certification. That component sits in a subassembly of a subassembly, and how deep the bill of materials goes is not known in advance: in SQL that forces a recursive query, in a graph it is a traversal. Component, bill of materials, serial number, installation and site become entities, and the links between them are declared once. The real work comes earlier, in recognizing that the supplier the question starts from appears under three different legal names: once that identity is resolved, the link stays. Where the graph is stored is a separate choice, which I cover in graph database.

Why now

The graph's structure, which entities exist and which relationships are allowed, is defined by the ontology: the two go together, the ontology is the schema, the graph is the living data. I devoted a separate article to why AI projects fail on the data rather than the model, with GraphRAG adoption numbers and the cases where a graph is not what you need.

Why it matters for decision makers

Three questions are worth putting to a vendor: who keeps ownership of the ontology when a process changes, how often the graph is refreshed from the source systems, and how a wrong relationship gets corrected while still knowing where it came from, which is why sources are kept apart in named graphs. The line almost nobody budgets for is maintaining the mapping between the graph and the systems feeding it. That is also where the risk moves: a graph that has stopped updating keeps answering, and it answers with the authority of an explicit structure, even when the data underneath is months old. A narrow perimeter kept alive is worth more than a complete map frozen three years ago.