One source of truth for people and AI is a single set of business definitions, each with a named owner, that both reports and AI tools read from. You need agreed definitions for the key terms, a link from each one to the reports and data that use it, and one place people and AI can both reach. A knowledge graph isn't required to start, but it's highly recommended once several teams and AI tools rely on those definitions.
At a glance
- One source of truth for people and AI starts with agreed business definitions, each with a named owner, not with a new data platform.
- A knowledge graph isn't required for a first use case, but it's highly recommended in larger setups, where many reports and AI tools need the same connected definitions.
- The same definition has to reach the report reader and the AI assistant from one place, or the two risk drifting apart.
Why one source of truth usually fails twice
Most companies have already tried this once, for reporting: a data warehouse, a certified dataset, a glossary on SharePoint. People still argued about the numbers because the data was centralised but the meaning wasn't.
AI makes that gap visible faster. For example, a project manager asks the company assistant how many active customers you have. The assistant finds three columns with “customer” in the name and picks one. Sales, Finance and the board dashboard each count active customers differently. Nobody is necessarily wrong. Nobody agreed.
In practice, a source of truth for AI is what a source of truth for people always needed: definitions someone owns, linked to the data they describe, and readable wherever the question is asked.
Do we need a knowledge graph or ontology before deploying enterprise AI?
Not strictly. But in larger setups it's highly recommended. A knowledge graph stores business terms and the relationships between them: this KPI, its definition, its owner and the reports that use it. An ontology adds formal rules about what those entities are and how they may relate. AWS offers GraphRAG backed by Neptune Analytics as an option in Amazon Bedrock Knowledge Bases, not as a requirement.
For one or two AI agents, you can often hardcode the context and skip the graph. That works while the scope is small and one team maintains it.
Larger setups are different. Once several chatbots, agents and teams depend on the same terms, every hardcoded copy has to be updated by hand, and the copies can drift apart. A graph lets them pull from one shared source. The design aim is to update a definition once and make that version available to connected reports and chatbots. Actual adoption depends on integrations, retrieval, caching and refresh processes, rather than guaranteed instant propagation. The graph also makes relationships explicit that a flat list alone doesn't capture: which KPI depends on which, which reports use a measure and who owns what.
One caveat: a graph models meaning you already have. If “active customer” means three things in three teams, the graph will hold three versions, or one wrong one. Agree the terms behind decisions first, and build the graph on that glossary. In practice, the two grow together.
What is a semantic layer for AI, and do we need one before deploying GenAI?
The term means different things depending on who uses it.
- In metrics tooling, a semantic layer is metric logic defined in code, intended to give tools a consistent way to calculate measures such as revenue.
- In Power BI, the semantic model holds the tables, relationships and measures that reports and Copilot use. Prep data for AI includes AI data schemas, AI instructions and verified answers to help reduce ambiguity. These features do not guarantee identical outputs.
- In a business sense, it's a layer that links business concepts together: this KPI, its definition, its owner and the reports it appears in. Its focus is business meaning rather than calculation code. Think of it as a business brain: the place where what your company means by its terms is written down and connected, so people and AI can read the same thing.
Do you need one before GenAI? You need the business meaning before GenAI. Whether it lives in code, in a semantic model or in a glossary matters less than whether it's agreed, owned and reachable by the AI. A glossary is often the first step.
What is a context layer for AI agents, and how is it different from a data catalog?
“Context layer” is a newer term. It usually means the information an AI agent receives alongside a question to help it answer correctly: what a term means, which dataset to use, who owns it and whether the data is fit to use.
A data catalog has traditionally been built for people: an inventory of data assets with descriptions, owners and lineage, searched in its own portal. The content overlaps heavily. The difference is mostly the reader and the delivery. A catalog serves people through search. A context layer serves agents through an interface they can call.
So the useful question isn't which label you buy. It's whether the definitions your people read and the ones your AI reads are the same ones.
Semantic layer, context layer, catalog and knowledge graph compared
These approaches aren't rivals. Most companies end up with several. What matters is where the agreed meaning lives and who can reach it.
| Approach | What it holds | Main reader | Who maintains it | Good first step for AI? |
|---|---|---|---|---|
| Semantic layer as code | Calculation logic for metrics | BI tools and developers | Data engineers | If metric logic is the main gap |
| Power BI semantic model | Tables, relationships, measures | Reports and Copilot | Model authors | If already in place, add descriptions and use Prep data for AI where available |
| Business glossary or catalog | Definitions, owners, links to assets | People | Data owners and stewards | Yes, if AI can reach it too |
| Context layer | Meaning, usage, ownership, quality for agents | AI agents | Depends on the setup | Yes, if fed by owned definitions |
| Knowledge graph or ontology | Entities and relationships; an ontology adds formal rules | Applications and AI | Specialists | Optional to start, highly recommended at scale |
What does a data catalog need to actually support a company chatbot that answers questions about our data?
Most catalogs were built for people searching a portal. To support a chatbot, check five things.
- Plain-language definitions for the terms people ask about, not only technical descriptions of columns.
- A named owner per definition, so the chatbot can say who to ask when it's unsure.
- Links to where each definition is used: the reports, measures and datasets behind it.
- Quality status, so the chatbot can flag when the data behind an answer has known issues.
- An interface AI tools can call, such as an API or an MCP server, with access controls that enforce who is allowed to see what. Verify those controls in the chosen implementation.
Two terms help here. Retrieval-augmented generation, as Microsoft and AWS describe it, retrieves relevant content from your own sources and passes it to the model with the question. The Model Context Protocol (MCP) is an open standard, introduced by Anthropic in 2024, for connecting AI assistants to external tools and data. Both can deliver access to a source of truth. Neither creates one.
How to get there: Pick, Define, Own, Link, Serve
- Pick: start with the terms behind decisions, such as the KPIs in management reports and the words people ask the AI about.
- Define: one plain sentence per term, including what's excluded.
- Own: one named person per term who can change it.
- Link: connect each definition to the reports, measures and datasets that use it. In larger setups, a knowledge graph holds these links in one place.
- Serve: make the same definition available to people in their reports and to AI tools through one interface.
Start with meaning, scale with connections
One source of truth for people and AI isn't primarily a new platform. It's the old promise of a shared meaning per term, made available to every reader. Agree the definitions, name the owners and make sure the report and the assistant can read the same text. Then connect them in a knowledge graph as more teams and AI tools rely on them. You can start without one. At scale, a graph is highly recommended to help keep readers aligned around a connected, maintained source of meaning.
Frequently asked questions
Can a data catalog be the source of truth for AI?
Yes, if it holds agreed definitions with owners and AI tools can query it under appropriate access controls. A catalog that only lives in its own portal serves people who go looking, not assistants that need to retrieve context while answering.
Is RAG enough to give our AI one source of truth?
RAG retrieves what you point it at. If it retrieves three conflicting definitions, it can pass all three to the model. RAG delivers access to the source of truth; it doesn't create it.
Can we skip the knowledge graph altogether?
For a single chatbot with a narrow scope, often yes. Once several agents and teams use the same terms, a graph is highly recommended because hardcoded copies of definitions can drift apart. A graph provides one connected source, with updating once as a design aim. Keeping consumers aligned still depends on integrations and refresh processes.
Where do we start if we have hundreds of undefined terms?
Start with the KPIs in management and board reports, and the terms people already ask the AI about. Define those, name owners and expand term by term. Modelling everything up front is how glossary projects stall.
Who should own the source of truth, IT or the business?
The business owns the meaning and IT owns the plumbing. Each definition needs one business owner who can change it. IT is responsible for connecting reports and AI tools to the shared source and maintaining the delivery processes that help them use the current version.