Knowledge Graphs: How to Represent a Company’s Knowledge

A knowledge graph is not a fad nor a universal solution. It is the
structure that appears when a company’s knowledge is, by
nature, a network of entities and relationships. When it is, there is no
reasonable alternative. When it is not, it is over-engineering.

Introduction

We have spent two days preparing the ground: the entities (who is who,
yesterday) and the relationships (where the business lives, yesterday). Today we join them and give them
the name we have been mentioning: knowledge graph.

But we are going to do it with a warning from the start, because it is the
one that is most lacking in enterprise AI conversations: a knowledge graph
is not a universal solution. Not all enterprise problems are
graphs. And presenting the graph as the answer to everything is the fastest way
for a project to die in the pilot.

The problem

An energy operator manages thousands of assets: turbines,
transformers, lines, substations. Each asset has a maintenance
history, an applicable regulation, a technical owner, a parts
chain and a relationship with the neighboring assets (a turbine that
feeds a substation that connects to a line).

When an asset fails, the operational question is not “where is the
history of turbine T-12?” (that is a lookup). It is a question of
scope and consequence:

“If turbine T-12 fails, which other facilities are affected, which
safety regulation is triggered, which parts are available and which
technicians are qualified for that repair.”

That question crosses: the asset and its neighbors (physical network), the regulation
applicable to that type of asset (regulation), the parts inventory
(supply chain), and the qualified personnel (resources). None of those
pieces is in one place. And the correct answer is not a document: it is
a traversed network.

The concept

A knowledge graph (KG) is a data structure that represents the
knowledge as a graph:

• Nodes → entities (a turbine, a contract, a customer, a
  regulation, a technician).
• Edges → relationships with direction and meaning (feeds,
  covers, requires, qualified_for).

Its minimal form is the triple (subject, relationship, object):
(turbine T-12, feeds, substation S-3). A KG is, in essence, a
enormous collection of coherent triples.

What distinguishes a KG from a table or a document is not the shape, it is
what it lets you do:

1. Traversal (graph retrieval). Go from one node to another following
   relationships, in one or several steps. “T-12 feeds S-3, and S-3 connects
   with L-7” — two steps, but a single operation.
2. Multi-hop reasoning. Answer questions that require chaining
   several relationships: “Which technicians are qualified to repair the
   turbines that feed substations in the north zone?” — this crosses
   asset→neighbor→zone→technician.
3. Inference. Derive relationships that are not explicit from the ones
   that are. If “T-12 feeds S-3” and “S-3 connects with L-7”, it can
   be inferred that T-12 “contributes to” L-7, even though nobody wrote that triple.
   (We will develop inference in detail on the reasoning day.)

When does it add value?

• When the knowledge is relational and cross-cutting: entities connected
  in a network, not in a line or in a tree.
• When the questions are of scope and impact: “what is affected if
  X fails?”, “who has to know?”.
• When there are rules and dependencies between entities that are applied at the
  moment of deciding.
• When you need traceability: each answer has a path of
  triples that justifies it.

When does it NOT add value?

• When the knowledge is simple hierarchical: a taxonomy of
  products, an org chart. A tree is enough.
• When the question is a direct lookup: “where is the contract
  of X?” An index or a RAG solve it without a graph.
• When the knowledge is massive and homogeneous: millions of
  tabular records without cross relationships. A relational or
  analytical database is more efficient.
• When the organization cannot maintain the graph: if the relationships
  are not updated, the graph rots and gives false confidence.

A wrongly chosen knowledge graph is more expensive than its absence, because it gives
the illusion of having solved the problem.

Comparison with what you already have

None of these structures is “better”. They are answers to different
questions. The architecture we will see later combines the four; today
it only matters to know which one answers what.

Architecture

In the series diagram, the knowledge graph is the materialization of the
relational knowledge:

                KNOWLEDGE
                     ↑
              KNOWLEDGE GRAPH   ← today: nodes + relationships + traversal + inference
                     ↑
          ┌──────────┴──────────┐
          ↓                     ↓
      ONTOLOGY          ENTITY RESOLUTION
   (relationship types)    (canonical entities)
                     ↑
                SEMANTICS / DATA

The KG is where the ontology (types), the canonical entities (yesterday) and the
concrete relationships (day 6) join into a queryable structure. It is
the “body of facts” layer we spoke about on the ontology day (the
skeleton of meaning was the ontology; the body of facts is the graph).

Use case

The energy operator, with its turbine T-12. We break it down:

1. Problem. Facing a possible failure of a key turbine, the team cannot
   quickly size the scope (which facilities, which regulation,
   which parts, which technicians) because the information is scattered across
   five systems.
2. Decision. Decide the contingency plan and the intervention
   window before the failure becomes an outage.
3. Knowledge needed. The neighbor network of T-12; the regulation
   applicable to its type; the available parts and their location; the
   qualified technicians and their availability.
4. Data. Asset sheets, maintenance history, regulation,
   inventory, personnel — in five systems, without the network connected.
5. Relationships. T-12 → feeds → S-3 → connects → L-7; T-12 → requires →
   part R-55; regulation N-9 → applies_to → turbine_type; technician T-3 →
   qualified_for → turbine_type.
6. Context. There is a maintenance window in two weeks; the
   regulation N-9 requires notification to the authority before intervening;
   two technicians are on sick leave.
7. Memory. The last failure of an identical turbine took 11 days due
   to lack of part R-55; the lesson (stock R-55) is in the report.
8. Reasoning. Traverse the network: which facilities are affected;
   cross with the inventory (is there an R-55?); cross with personnel (are there technicians
   available?); apply the regulatory constraint (prior notification).
9. Action. Generate the contingency plan with the window, the parts
   to reserve, the technicians to assign and the regulatory notification
   in the queue.
10. Infrastructure. The asset+regulation+inventory+personnel graph
    • the multi-hop reasoning that crosses the four sub-networks + the memory
      of the previous incident. The graph appears as a consequence of the need
      (to size the scope), not as a starting point.

Trade-offs

• Cost. A useful KG costs to build: you have to decide which entities and
  relationships to model, where each piece of data comes from, and how it is maintained. It is not a
  weeks-long project.
• Complexity. Modeling badly (too many or too few relationships)
  produces a graph that is either unusable or is a mess. The prior ontology
  (day 4) is what avoids the mess.
• Quality and maintenance. A graph with outdated relationships gives
  false confidence: the agent answers with certainty about a world that no longer
  exists. Maintenance is part of the cost, not an extra.
• Latency. Multi-hop traversals on large graphs are more
  expensive than a SQL query. It is mitigated by precomputing the traversals
  that matter and limiting the depth.
• Scalability. Graphs of millions of nodes/edges require
  specific infrastructure (graph databases, partitioning). For many
  companies, a graph of tens of thousands of well-modeled entities is more
  useful than one of hundreds of millions poorly modeled.
• Honest limitation: the KG represents structured knowledge.
  The part of the knowledge that is in prose (manuals, policies,
  reports) does not enter the graph directly: it has to be extracted, and that is
  RAG and extraction work (tomorrow and the RAG day). The graph and the RAG
  are complementary, not rivals.

Implication for the company

For the CDO, the knowledge graph is the way to represent the relational
knowledge of the company — the one that today lives in people’s heads — in such a way
that a system can traverse it. And it is a selective asset: it is worth
building it where there are cross relationships and impact decisions, not
everywhere equally.

For the AI team, the lesson is one of engineering: it is not about “putting a
graph”, but about deciding which knowledge deserves to be a graph and which is
text for the RAG. That decision is what separates a useful KG from a
bloated project.

For top management, the message is one of capability: the scope and impact
questions (“what happens if X fails?”) are the ones that today paralyze the company,
and they are the ones a well-built graph turns into queries.

Conclusion

A knowledge graph is the structure that appears when the knowledge of
a company is a network of entities and relationships: nodes, edges with
meaning, multi-hop traversal and inference. It adds value when the
knowledge is cross-cutting relational and the decisions are of impact; it is not
a universal solution, and presenting it as one is an expensive error.

Today the graph is built and queryable. But there is a problem we have not yet
touched: the moment an agent needs an answer, how
does it get to the exact part of the graph (or of the document corpus) that it needs?
Retrieval is a discipline of its own, and it has names and tricks that
are worth knowing before assuming that “the model will find it”.

Next article

Tomorrow: RAG Is Not Memory: What’s Missing After You Retrieve a Document. We will see what RAG actually does, what it does not do, and why the
correct question is not “do we retrieve the document?”, but “do we retrieve the
knowledge necessary to make the decision?”.

Sources

• Working definition of the ICE: see series, Day 1.
• Microsoft Research (2024). GraphRAG. — Global/local search over knowledge
  graphs (context for the comparison with RAG).
• Graph representation and multi-hop reasoning are standard concepts
  of knowledge representation and semantic web (W3C).