Signed in as:
filler@godaddy.com
Knowledge Graph
Making organisational knowledge connected and computable
Organisational knowledge does not exist as isolated documents. People own systems. Systems support business capabilities. Policies govern processes. Processes use data. Standards constrain architectures. Projects implement decisions. Decisions respond to requirements. Customers enter contracts. Products depend on services.
These relationships often exist implicitly across thousands of documents and systems. A Knowledge Graph makes selected entities, concepts and relationships explicit so that people and machines can navigate, query and reason over connected knowledge.
Documents tell us what was written. A Knowledge Graph helps us understand what is connected.
What Is a Knowledge Graph?
A Knowledge Graph represents knowledge using identifiable entities or concepts connected by relationships. At its simplest:
PERSON ── owns ──►SYSTEM ── supports ──►BUSINESS CAPABILITY
The graph makes the relationships explicit. Instead of knowledge being understood only from paragraphs of text, systems can directly represent statements such as:
Team A ── owns ──► Customer Platform ─ supports ──► Customer Onboarding
Customer Onboarding ── governed by ──► Customer Verification Policy
This creates a different way of navigating organisational knowledge. The question is no longer only:
- Which document mentions Customer Onboarding?
It can become:
- Which systems support Customer Onboarding?
- Who owns those systems?
- Which policies govern the process?
- Which standards apply?
- Which architectural decisions affect those systems?
That is where graph-based knowledge becomes valuable.
Knowledge Is Connected
Consider a conventional document environment.
- policy.pdf, architecture.docx, system-register.xlsx, meeting-notes.doc, standards.pdf
Each document may contain important knowledge. But the relationships between them often exist only inside prose or inside someone's understanding.
A Knowledge Graph makes selected relationships explicit as shown in the diagram. This connected representation can coexist with the original documents. The graph does not need to replace them.
Knowledge Lake and Knowledge Graph
Within the Acta Laurel architecture, the Knowledge Lake remains the persistent foundation. The Knowledge Graph provides a graph-oriented representation or service over selected knowledge.
This distinction protects the architecture from making the graph database the sole owner of organisational knowledge. The Knowledge Lake can preserve portable knowledge. The graph can optimise how connected knowledge is represented, traversed and queried.
Concept Link Graph vs Knowledge Graph
A file-oriented Knowledge Lake can already contain links between Knowledge Concepts.
For example:
# Customer Platform
The platform supports
[Customer Onboarding](../capabilities/customer-onboarding.md).
Those links create a graph:
Customer Platform ──► Customer Onboarding
Acta Laurel refers to this baseline structure as a Concept Link Graph. That wording is deliberate.
A collection of linked Markdown documents should not automatically be presented as a sophisticated Enterprise Knowledge Graph. A richer Knowledge Graph may introduce capabilities such as:
- persistent entity identity;
- typed relationships;
- explicit schemas;
- controlled vocabularies;
- provenance;
- graph constraints;
- validation;
- external entity integration;
- semantic modelling;
- reasoning or inference where justified.
Conceptually:
DOCUMENT LINKS ──►CONCEPT LINK GRAPH ──► TYPED RELATIONSHIPS ──►CONTROLLED SEMANTICS ──►KNOWLEDGE GRAPH ──►ADVANCED SEMANTIC /
REASONING CAPABILITIES
Not every organisation needs to progress through every stage.
Entities, Concepts and Relationships
Web Development
Three ideas sit at the centre of a Knowledge Graph.
Identity
A graph needs to know what thing is being represented. Names alone are insufficient. There may be two employees named John Smith. Two jurisdictions may both have a policy called Data Retention Policy. A system can be renamed without becoming a different system. A graph therefore requires stable identifiers for important entities and concepts.
IDENTITY
│
├── label: "Customer Platform"
├── type: System
└── identifier: stable identity
The label can change. The identity should remain stable.
Relationships
Relationships describe how entities or concepts are connected. Examples include:
PERSON
└── member of ─────► TEAM
TEAM
└── owns ──────────► SYSTEM
SYSTEM
└── supports ──────► CAPABILITY
POLICY
└── governs ───────► PROCESS
STANDARD
└── constrains ────► ARCHITECTURE
DECISION
└── affects ───────► SYSTEM
A relationship should communicate genuine meaning. This becomes especially important when relationships are intended for machine processing.
Semantics
Not all links mean the same thing. Consider:
Policy A ─────► System B
What does the relationship mean? Does the policy:
- govern the system?
- reference it?
- apply to it?
- replace it?
- constrain it?
A richer graph makes the relationship explicit:
Policy A
│
└── governs ─────► System B
Typed relationships make the graph more useful for queries, validation and automated interpretation.
Knowledge Graph and Search
Search and graph traversal solve different retrieval problems.
Keyword search
Useful when the user knows the terminology.
Find documents containing "customer retention".
Semantic search
Useful when meaning is similar but wording differs.
Find material about keeping existing customers.
Graph query
Useful when the relationship itself is important.
Which products are affected by policies owned by the Compliance function?
The architecture can combine them as the image shows. This combination is significantly more powerful than treating any one retrieval method as universal.
Knowledge Graph and AI
Knowledge Graphs can provide valuable context to AI systems. A language model is good at interpreting language. A graph is good at explicitly representing known relationships. Together they can address different parts of the knowledge problem.
An AI agent might use semantic retrieval to identify relevant concepts and then use graph traversal to expand their organisational context.
For example if we have the Question: "What could be affected if Customer Platform is unavailable?" we can see in the image how it can be split.
The graph helps the AI discover connections that may not appear together in one document.
Graph-Enhanced Retrieval
A conventional retrieval pipeline might look like:
QUESTION ──►VECTOR SEARCH ──►DOCUMENT CHUNKS ──►LLM
A richer knowledge architecture can include a bit more like the image on the left demonstrate.
This is not simply a larger RAG pipeline. It introduces explicit organisational knowledge structure into retrieval.
Knowledge Graph and the Knowledge Warehouse
The Knowledge Graph is one of the capabilities that can support a Knowledge Warehouse. The Knowledge Warehouse provides the broader enterprise capability. The graph provides connected knowledge representation and traversal. This distinction keeps the architecture modular.
Not Every Relationship Must Live in Files
The reverse is also important. Some graphs may integrate relationships from enterprise systems that do not belong in the file-oriented Knowledge Lake. The enterprise graph can therefore integrate multiple authoritative sources.
The Knowledge Lake is a major knowledge source. It does not need to pretend to be the source of every enterprise fact.
A Federated View of Knowledge
This leads to a broader enterprise architecture. The graph can connect knowledge without requiring all knowledge and data to be physically centralised.
Human-Created and Machine-Created Relationships
Relationships can enter the graph through several mechanisms. These should not necessarily have identical trust.
A relationship imported from an authoritative asset-management system may have different status from one inferred by an LLM from meeting notes.
Provenance and trust signals allow those differences to remain visible.
Acta Laurel's Architectural Position
Architectural Position
The Knowledge Graph occupies a specific place within the wider Knowledge Architecture. The Knowledge Lake preserves explicit knowledge and sources. The Knowledge Graph makes selected relationships computationally explicit.
The Knowledge Warehouse provides enterprise services through which connected knowledge can be discovered and applied.
AI becomes one consumer—and potentially one contributor—to this environment.
Controlled Vocabulary Foundation
For controlled vocabulary and Knowledge Organisation Systems, Acta Laurel draws on work surrounding SKOS and semantic knowledge organisation.
This supports a deliberate distinction between:
CONTROLLED VOCABULARY ──► TAXONOMY ──►KNOWLEDGE ORGANISATION SYSTEM ──► ONTOLOGY
These structures can contribute to a Knowledge Graph without being interchangeable with it.
From Documents to Connected Knowledge
Most organisations already contain the relationships that a Knowledge Graph seeks to represent. They exist in people's heads. They exist in diagrams. They exist in spreadsheets. They exist inside application databases. They exist in paragraphs scattered throughout documents.
The problem is that those relationships are often difficult for the organisation to use systematically.
A Knowledge Graph makes selected relationships explicit, addressable and computable.
INFORMATION
│
EXPLICIT KNOWLEDGE
│
IDENTIFIED CONCEPTS
│
EXPLICIT RELATIONSHIPS
│
KNOWLEDGE GRAPH
│
HUMAN / SYSTEM / AI
│
CONNECTED UNDERSTANDING
The purpose of a Knowledge Graph is not to draw more connections. It is to make important organisational relationships explicit enough to be understood, governed and used.