A plain-language guide to knowledge graphs, semantic layers, and why Enterprise Architecture was on the right path from the very beginning.
There is a question that sounds simple but keeps tripping up organisations spending millions on data infrastructure:
Why can't AI just answer the question? The data is all there.
The data is there. That's true. But data and meaning are two different things. Most organisations have invested heavily in the first while quietly ignoring the second.
This piece is about that gap, why it matters more than ever, and what closing it actually looks like in practice.
Imagine you're a very smart new employee
You just joined a company. You're brilliant - you've read millions of books, you speak perfectly, and you can do maths in your head instantly. But it's your first day.
Your manager walks up and says:
"Can you check if the conversion was good last quarter?"
You freeze. Not because you're stupid. But because you don't know:
Does "conversion" mean sales leads turning into customers? Or the euro-to-dollar exchange rate? Or a file being saved in a different format?
What counts as "good"? Good compared to last year? Good compared to a competitor? Good for which team?
What is "last quarter" in this company? Do they run January–March, or is their fiscal year different?
You have intelligence but no context. And without context, you cannot reason correctly. You'd just be guessing.
That new employee is the AI.
This is not a flaw in the technology. It is an honest reflection of what AI systems are: extraordinarily capable reasoners that know nothing specific about your organisation unless you tell them. They are brilliant generalists dropped into a room full of specialist filing cabinets, with no map and no guide.
The filing room problem
Picture your organisation's data as a large room full of filing cabinets. Each one is labelled and well-organised inside. The sales cabinet has sales data. The finance cabinet has revenue data. The marketing cabinet has campaign data.
But here's the thing: The cabinets don't talk to each other.
The sales cabinet doesn't know it's related to the finance cabinet. Nobody wrote on the outside: "Hey, when a sale closes here, it eventually shows up over there as revenue - usually 30 days later."
That connection exists only in the head of the finance director who's been there 12 years.
So when the AI is asked "Did our Q3 marketing campaign make us money?" - it can open each cabinet just fine. It can read every column, every row, every figure. But it doesn't know why they're related, in what order things flow, or what the words inside actually mean in this company's language.
It will answer. It will sound confident. But it will be guessing.
The map on the wall
Now imagine someone - typically a seasoned Enterprise Architect, a data steward, or a senior analyst who's been around long enough to know where all the bodies are buried - sits down and draws a map.
On that map they write things like:
"Conversion" here means a lead becoming a paying customer - see the Sales cabinet, column 4.
"Marketing spend influences pipeline revenue - but with a 6-week delay."
"Net revenue excludes refunds and VAT. It is NOT the same as gross revenue."
"When the CFO asks this question, she means by product line. When Sales asks it, they mean by region."
That map doesn't replace the filing cabinets. The data still lives where it lives. But the map tells anyone - human or machine - what everything means, how it connects, and why.
This is what a semantic layer does. In more technical circles it is called a knowledge graph, an ontology layer, or a context graph. The name matters less than the function: it is your organisation's reasoning, written down in a form that machines can read.
Why AI specifically needs this
AI systems are, at their core, very fast pattern matchers trained on enormous amounts of language. They learned from the internet - which means they learned many possible meanings of every word.
Without your specific map, they will default to the most common meaning, not your meaning:
"Pipeline" might be read as a water pipe, or a software deployment process - not your sales pipeline.
"Net" might be a fishing net, or the internet - not net revenue after refunds.
"Conversion" might be currency exchange - not the metric your marketing team lives and dies by.
The semantic layer is how you tell the machine: "In this organisation, these are the rules."
Once it has that map, it stops guessing. It knows that when the CMO asks about conversion, she means leads to customers, measured against the target set in the annual plan, compared to the same period last year. It knows the 6-week delay between campaign spend and revenue recognition. It knows that "good" means above 3.2%, because that's the threshold your business defined.
It doesn't guess any of that. It reads it from the map.
This is an Enterprise Architecture problem in disguise
Here is what makes this interesting for anyone who has worked in Enterprise Architecture: this is not a new problem.
EA frameworks like TOGAF and ArchiMate have been making exactly this argument for decades. Define your business capabilities. Map your information flows. Document your canonical data definitions. Surface the reasoning behind decisions, not just the decisions themselves. Keep the logical view of your organisation - what things mean and how they relate - separate from the physical view of where data actually lives.
The knowledge graph is that logical view, made machine-readable.
Which means organisations that have done their EA work carefully - that have a business glossary, a capability model, a proper information architecture - are sitting on the raw material for a knowledge graph already. They have a head start that companies who skipped that work and went straight to building data platforms do not.
The urgency is new. The discipline is not.
What is new is that machines now need to read the output. An EA deliverable that only humans ever consulted was better than nothing. But today, if your organisational reasoning isn't encoded in a form that a machine can traverse, query, and reason over - it effectively doesn't exist for the systems you're asking to run your business.
What "meaning" actually looks like in practice
To make this concrete: meaning in this context is not philosophy. It is three very specific things, working together.
The definition of your terms. Not the dictionary definition - your organisation's definition. What does "active customer" mean in your business? Is it anyone who bought in the last 12 months? The last 6? Anyone with an open contract? This definition lives differently in Finance, in Sales, and in Customer Success - and a machine needs to know which definition applies and when.
The relationships between your concepts. Campaign spend influences pipeline revenue. Net revenue drives bonus disbursement. NPS is a leading indicator of churn. These relationships are the organisational knowledge that nobody ever wrote down because everyone assumed everyone else already knew it. The semantic layer makes them explicit and traversable.
The context of who is asking. A CFO and a regional sales manager looking at the same underlying data need different framings, different aggregations, and different vocabulary. The semantic layer can hold those differences - not to rebuild personalisation from scratch, but to ensure that when the AI retrieves and presents information, it does so in the right frame for the right person.
Together, these three things transform data from a collection of facts into something a machine can actually reason with.
In three sentences
Data is the facts. Meaning is the story that connects the facts. AI can read the facts perfectly — but it needs you to write down the story first.
That is what a knowledge graph does.
And that is why, from an Enterprise Architecture perspective, this is not really a technology problem. It is a knowledge management problem that EA has been trying to solve for decades - with new urgency now that machines need to read the answer too.
The organisations that treat this as a quick technical fix will build pipelines that answer questions confidently and incorrectly. The organisations that treat it as the architectural discipline it actually is - patient, deliberate, grounded in how the business actually works - will build something that gets smarter over time.
The map on the wall has always mattered. We just never had to make it this legible before.
This blog post draws on concepts from What Makes Knowledge Graphs AI-Ready by Animesh Kumar, published in Modern Data 101.
My content is carefully prepared, crafted and takes anywhere from a few days to several weeks. I sacrifice my free time to create high quality content for you.
The easiest way you can support ♥️ me? Subscribe, like and share this article.
If you like to know more about me, please contact me directly or visit my LinkedIn profile.