Best Practices for Implementing a Semantic Layer

If you want to understand why your data needs a semantic layer, look at what happens to AI without one. Without semantics, your best case is forcing a massive JSON payload into an LLM to explain what your data means. The worst case? AI blindly wanders through undocumented data, guessing based on statistical probability rather than actual logic. Neither outcome is acceptable for organizations building reliable, production-grade AI. As Meagan Palmer recently noted, the semantic layer has historically had two meanings: one from BI/data management, and one from the Semantic Web. Yesterday Jessica Talisman did a deep dive on the history of semantic layers cracking open the fine-grained detail. (See comments for links). To truly support AI, you must unify both types of semantics. Here's a Crawl → Walk → Run progression for evolving your metadata stack into a unified form: Crawl: Structure and Best Effort Semantics — Centralize metadata into JSON Schemas and glossaries. Move away from fragmented silos by adopting a unified metadata model capturing first-class entities like tables, dashboards, and pipelines. This establishes clearer definitions across your organization. But this is still just best effort semantics. Flat definitions create dangerous ambiguity AI cannot resolve alone. Ask what revenue means and Finance says "Net", Sales says "Gross", Marketing says "Attributed". Without explicit architectural meaning, AI fills that gap with probability — delivering confident but wrong answers. Walk: From Metadata Graph to RDF — Make your metadata machine-understandable. Translate JSON schemas into an RDF graph of subjects, predicates, and objects. Starting with schema.org means analysts work in familiar JSON while that structure translates into formal formats like JSON-LD without complex context switching. The result is a knowledge graph built on standard vocabularies like DCAT for datasets and PROV for lineage, layered with data quality, ownership, and usage context. This enables GraphRAG, SPARQL queries, and cross-system connectivity. Run: Ontologies and AI Reasoning — Evolve from a flat glossary to a full knowledge ontology. Instead of defining a customer as simply a person who buys goods, map exactly how that entity relates to domains, metrics, revenue streams, and orders. Connect that ontology to your physical data estate by tagging real tables and columns to concepts in your OWL ontology. The result: you move beyond context-driven approximations like vector similarity to a true semantics-driven system. AI agents consume structured semantic context to execute cognitive logic. Definitions and relationships are explicitly governed, so answers are precise, consistent, and explainable. Not statistical guesses. You've stopped standardizing metadata. You've started standardizing meaning. #DataStrategy #SemanticLayer #AIData #KnowledgeGraph #DataManagement #EnterpriseAI #Ontology #DataGovernance #RDF

(Part 4 of my series: The Boardroom Guide to AI-Ready Data Strategy) For years, organisations debated Data Lakes vs. Data Warehouses. But today, that debate is irrelevant. 1. Infrastructure has become a commodity. 2. Compute is cheap. 3. Storage is cheap. 4. Pipelines are automated. The real bottleneck to scaling AI isn’t technology. It’s meaning. If Marketing, Finance, Risk, and Product all define foundational terms differently , “Customer”, “Revenue”, “Churn”, “Exposure”, your AI systems will fail instantly. They will generate plausible-sounding nonsense based on conflicting definitions. This is why modern AI-driven organisations are shifting from infrastructure debates to semantic alignment. The 3 Architecture Priorities for AI-Ready Enterprises 1️⃣ Decouple Compute & Storage So you can scale elastically, control costs, and avoid vendor lock-in. 2️⃣ Build a Semantic Layer A unified business logic layer sitting above your physical data. It defines metrics, joins, relationships, and meaning — consistently across the enterprise. This becomes the “Rosetta Stone” for your LLMs and Agentic AI systems. 3️⃣ Move to Data Products Instead of fragile pipelines, build domain-owned, SLA-backed, well-documented data products. This accelerates cross-team adoption and eliminates ambiguity. You don’t fail at AI because your model is weak. You fail because your definitions are weak. If your organisation wants reliable GenAI, RAG, and autonomous agents, your first investment is not GPUs, it is the Semantic Layer. Don’t just modernise your stack. Modernise your logic. #DataArchitecture #SemanticLayer #DataProducts #DataMesh #AIStrategy #EnterpriseArchitecture #GenAI #ModernDataStack

Beyond Prompts: Why Your AI Strategy Needs a "Semantic Layer" In my last article, I argued that the biggest hurdle for AI is human, not technical. We focused on building "Change Fitness"—the organizational muscle to adapt. We discussed literacy, redesigned workflows, and a culture of experimentation. But what happens when your newly "fit" organization starts deploying multiple AI agents? When your marketing chatbot, your sales forecast agent, and your product design co-pilot all need to work together on a single customer journey? You hit a new, silent wall. The problem isn't processing power or model capability. It's meaning. Today, we move from building the team to building the system that allows the team to think together. The critical infrastructure for this isn't found in your cloud provider's dashboard. It's the Semantic Layer: the shared language and understanding that allows humans and AI agents to collaborate with purpose, not just exchange data. Without it, you don't have an intelligent enterprise. You have a tower of Babel filled with very fast, very confused machines. The "Lost in Translation" Problem at Scale Imagine a simple cross-department goal: "Increase high-value customer retention." To your CRM agent, "high-value" might mean "purchased a premium plan in the last 90 days." To your support bot, it might flag "any user who opened more than 3 tickets," seeing them as at-risk. To your product analytics agent, it might define them as "users with a weekly session duration > 1 hour." Three agents, three conflicting definitions, working at machine speed. The result? Chaotic, contradictory actions. The marketing agent offers a discount to a user the support agent just flagged as abusive. The system is data-rich but meaning-poor. This is the chaos of a missing Semantic Layer. It’s not a software bug; it’s a strategic and communicative failure. The Three Pillars of a Strategic Semantic Layer Building this layer is not an IT task. It is the core strategic communicator's next mandate. It involves defining: 1. The Lexicon of Intent This moves beyond a simple data dictionary. It's a living document that defines core business concepts with nuance, context, and strategic intent. Don't just define "Customer Churn." Do define "Voluntary Churn vs. Product-Gap Churn," along with the business logic for why the distinction matters and the different actions each should trigger in your AI ecosystem. This lexicon becomes the common source of truth that every AI agent is trained and aligned against. It encodes your company's strategy into a machine-readable format. 2. The Protocols for Collaboration How do agents "talk" to each other? It's more than an API call. It's about passing context, confidence, and intent. A workflow shouldn't just be: Support Agent → [Flagged User] → CRM Agent → [Sends Coupon]. More in link.

📌 The Future of Agentic Analytics in BI There’s a growing misconception right now... That layering AI into your dashboards will magically transform your analytics. There’s a lot of hype around AI agents in analytics: ⤷ Natural language interfaces. ⤷ Auto-generated insights. ⤷ Chat-based dashboards. You might’ve even heard of the term Agentic Analytics The promise is that business users will be able to “ask anything” and get instant answers from data. But here’s the problem no one’s talking about: Most organizations aren’t ready for AI agents yet. Not because the tech isn’t mature. But because their data context is broken. → If your KPIs are misaligned across teams… → If your semantic layer is missing or incomplete… → If no one trusts how metrics are calculated… Then all an AI agent will do is generate faster wrong answers. You’ll get output but not outcomes. Before you invest in Agentic Analytics, ask yourself: 1) Do we have a single source of truth for our KPIs? 2) Is our semantic layer well-structured and governed? 3) Are stakeholders confident in the meaning behind the metrics? 4) Can business users explore data on their own? If not, the priority isn’t AI. It’s trust, structure, and shared understanding. That’s why the recent Salesforce acquisition of Informatica makes perfect sense. While the market chases the next flashy analytics tool, Salesforce is investing in the fundamentals: → Data integration → Metadata → Governance Because they understand this: AI is only as effective as the context it runs on. Here’s what I’ve seen work in the real world: 1️⃣ 𝐒𝐭𝐚𝐫𝐭 𝐰𝐢𝐭𝐡 𝐲𝐨𝐮𝐫 𝐬𝐞𝐦𝐚𝐧𝐭𝐢𝐜 𝐥𝐚𝐲𝐞𝐫 Define your KPIs, dimensions, and filters like you’re building a product. 2️⃣ 𝐃𝐨𝐜𝐮𝐦𝐞𝐧𝐭 𝐛𝐮𝐬𝐢𝐧𝐞𝐬𝐬 𝐥𝐨𝐠𝐢𝐜 Explain what each metric means and where it comes from. 3️⃣ 𝐀𝐥𝐢𝐠𝐧 𝐚𝐜𝐫𝐨𝐬𝐬 𝐝𝐞𝐩𝐚𝐫𝐭𝐦𝐞𝐧𝐭𝐬 Marketing, sales, ops should all speak the same data language. 4️⃣ 𝐁𝐮𝐢𝐥𝐝 𝐝𝐚𝐭𝐚 𝐭𝐫𝐮𝐬𝐭 Through consistency, transparency, and usage-based feedback. 5️⃣ 𝐃𝐞𝐩𝐥𝐨𝐲 𝐀𝐈 𝐀𝐠𝐞𝐧𝐭𝐬 Then and only then you can explore AI as a layer on top of a solid foundation. BI without context is just noise. And AI without structure is just risk at scale. If you’re serious about improving decision-making in your business, fix your foundations first. The tools will come and go. Context is what makes them useful. #DataStrategy #BusinessIntelligence #DataGovernance

Everyone is being sold knowledge graphs. Almost no one is being told where to start. Every major consulting firm is pitching knowledge graphs and context graphs right now. I’ve been in more than a few rooms this year where leaders are being told that autonomous AI agents, running on top of a knowledge graph, are the next strategic move. That part isn’t wrong. What’s missing is how you actually get there. Because you don’t go from inconsistent data, siloed systems, and loosely defined metadata… to autonomous agents making decisions on top of a knowledge graph. That gap isn’t small. It’s foundational. And most organizations are being sold the finish line before they’ve done the legwork to get there… jumping straight to ontologies and graphs before the foundation exists to support them. The better question is... what do we need to be able to answer, consistently, across the business? In knowledge engineering, these are competency questions. Questions like: Does this customer qualify for a flight refund for a three-hour mechanical delay? If different systems, teams, or analysts answer that question differently, you don’t have a graph problem. Your business doesn’t know what it knows problem. What most firms skip is that the semantic layer isn’t a single implementation. It’s a progression. It starts with controlled vocabulary... one agreed term for each concept. Not “client” in one system and “customer” in another. Then taxonomy adds structure... how those terms relate in a hierarchy. Then a contextual data model: for a given use case, what entities matter, and how do they connect in your business, not in theory? Only after that do you move into ontology... formal rules and relationships that allow the system to reason. And finally, connected data, where those definitions and rules are tied to real sources, governed, and traceable. A knowledge graph is the full expression of that stack. Not the starting point. Often not even the immediate goal. Most organizations already have the data. What they don’t have is shared meaning and the guardrails that keep AI from confidently being wrong. That’s why reporting breaks, reconciliation lives outside the system, and AI outputs feel right until you actually need to rely on them. So if knowledge graphs aren’t the starting point... what is? For your target use cases, write down the 10 most important questions your agent needs to answer. Then ask: what concepts make up those questions, and where does that information exist today? Systems of record? Policy documents? Tribal knowledge? Organizations with real knowledge graph maturity started exactly here. It may feel basic. But it isn’t. If you want a foundation for autonomous decision-making, it starts with understanding the concepts behind the questions. Question. Vocabulary. Structure. Context. That’s what everything else depends on.

Many ask themselves, «Why would I use a semantic layer? How to build one?». But a better question is: How many times have you implemented the same revenue calculation differently across your company's dashboards, reports, and apps? This is why semantic layers exist. With a semantic layer, your revenue KPI or other complex company measures are defined once in a single source of truth—no need to re-implement them over and over again. In my latest article, we'll have a look at the simplest possible semantic layer, which uses a simple YAML file (for the semantics) and a Python script for executing it with Ibis and DuckDB.  The goal is not to build a full-blown semantic layer, but rather to understand the value of such layers. We query 20 million NYC taxi records with consistent business metrics executed using DuckDB and Ibis. By the end, you'll know precisely when a semantic layer solves real problems and when it's overkill. It's a topic that I'm passionate about as I've been using semantic layers within a Business Intelligence (BI) tool for over twenty years, and only recently have we gotten full-blown semantic layers that can sit outside of a BI tool, combining the advantages of a logical layer with sharing them across your web apps, notebooks, and BI tools. ✨ Some of the Chapters and Insights: - When you DON'T need a Semantic Layer - Why use a semantic layer with the differentiation of «Datasets vs. Aggregations» - think of it this way: » dataset ≠ aggregations » table columns ≠ metrics » physical table ≠ logical definition If you find yourself needing the concepts on the right side, that's when you need a semantic layer, either for building into a BI tool or implemented separately. - A practical example with DuckDB, Boring Semantic Layer (by Julien Hurault and Hussain S.), and Ibis. Building a Domain-specific language (DSL) for our Metrics and KPIs. - Round up with common questions about the Semantic Layer, such as can't we use a database, or a database View for it? Should we use MCP, and what are the popular semantic layer tools? I hope you enjoy. Read the full essay here: https://lnkd.in/edB7uGVr. Happy to discuss further. Exciting times ahead for BI and for the semantic layer. PS: It's on the front page of Hackernews right now (30 position), but peaked yesterday evening :)

Gartner "Semantic layer non-negotiable, especially for AI Agents" Here's why this is something every AI team should consider... Most AI systems today fail not because the model is weak, but because the retrieval layer beneath it lacks understanding of context, relationships, or meaning. It doesn't matter how powerful your LLM is if it's reasoning on the wrong information. Let me break down core architectures, explaining why the semantic layer is so important, especially for AI agents. 📌 RAG (Retrieval-Augmented Generation) The foundation. Simple but limited. 1\ Query enters the system 2\ Data gets converted into dense numerical vectors 3\ Vectors get stored in a Vector DB 4\ Most relevant vectors are retrieved 5\ Retrieved info combines with query and system prompt 6\ LLM generates the final output No memory. No planning. No self-correction. 📌 Agentic AI A full multi-agent workflow for deep enterprise search. 1\ Query Agent breaks the problem down using memory and planning 2\ Control Agent orchestrates the entire workflow 3\ Retriever Agent fetches data through MCP Servers and Google Search 4\ Data Agent pulls structured records from internal databases 5\ Every agent runs in parallel — no bottlenecks 6\ Generator synthesizes everything into one final coherent response Every agent specialises. The Control Agent ensures nothing breaks. Recently, I came across a research paper that perfectly defined an architecture best suited for enabling graph RAG processes in an agent It was termed Graph R1. Let me explain what it does. 📌 Agentic Graph RAG (Graph-R1) Now there's a reasoning brain behind retrieval. 1\ Agent builds a knowledge hypergraph; mapping entities and relationships 2\ Agent thinks about the query before retrieving anything 3\ Generates a targeted retrieval query 4\ Retrieves relevant nodes and relationships from the graph 5\ If the answer isn't strong enough, it rethinks and queries again 6\ RL feedback loop scores output using F1 Score and Format Score 7\ Agent self-corrects before generating the final response It doesn't just find data; it understands how data connects. The semantic layer is the difference between an AI agent that sounds intelligent and one that actually is. If you want to learn more about this architecture, I'll attach the research paper in the comments along with the Gartner report. TLDR:- Trustworthy AI isn't optional anymore, it's the standard. Hallucination is a risk we can no longer afford, and a strong semantic layer is what keeps your AI systems grounded in truth 📌 If you want to understand AI agent concepts deeper, my free newsletter breaks down everything you need to know: https://lnkd.in/gg8rNvCq Save 💾 ➞ React 👍 ➞ Share ♻️ & follow for everything related to AI Agents

Believer in the semantic layer for analytics agents? Here's the actual playbook to make it work 📖 I'm back with my context engineering studies. Last time I tested the dbt Labs semantic layer, it was kind of a fail: my Cursor-generated semantic layer could barely answer 4% of questions 🆘 This time, with a few iterations on my semantic layer + extra context, I reached 82% reliability on my agent 🍀 tl;dr: invest in your data model + semantic layer, but don't forget to provide context engineering to orient your agent in the semantic The 7 key elements that got me there: 1️⃣ Use dbt semantic layer skills to build your semantic layer 2️⃣ Use the dbt natural language querying skill so the agent can choose between semantic layer and SQL 3️⃣ Make your data model and semantic layer exhaustive: the more metrics and dimensions you pre-compute, the more questions fall in scope 4️⃣ Review your entities and keys manually - bad joins = crazy answers 5️⃣ Add business context in your semantic layer descriptions - the agent needs them to pick the right metrics and filters 6️⃣ Add agent rules: date filtering, null handling, ambiguous questions. The semantic layer alone doesn't solve these 7️⃣ Add a context layer on top - to reduce hallucinations and costs in discovering the semantic layer Full results 👉🏻 https://lnkd.in/enwY7Vut

Finding the right balance between governance and flexibility is crucial when implementing a semantic layer. A semantic layer can serve as a platinum or certified data layer, where all metrics and key indicators are pre-calculated and approved by the central data team. But real-world data work isn’t static—data analysts and consumers need the ability to build on top of predefined metrics and explore ad hoc insights that might later be incorporated back into the certified layer. To enable this, two key architectural capabilities are essential: 1️⃣ Ability to create derived calculations – Allowing users to extend and build on top of certified metrics. 2️⃣ Ability to quickly iterate on changes to the semantic layer – Experimentation is critical, and making changes easily—in a separate environment, without disrupting the entire system—helps teams refine and improve their models. At Cube, we’ve built a SQL interface to query metrics, giving users the full power of SQL to create derived calculations on top of certified metrics. And for rapid semantic layer prototyping and development, AI Agents are shaping up to be a game changer. We've seen AI copilots and agents making serious strides in software development, even building full web apps. Since Cube's semantic layer is code, it's only natural—if AI Agents can write code, they can help analysts and data teams iterate on the semantic layer, prototype new models, and bring changes to production faster than ever. 🚀 The future of AI-assisted data governance and self-service analytics is within reach. More on finding the right balance between governance and flexibility here: https://lnkd.in/dQgH9sa4