Your Semantic Layer is Not Another Developer Tool

There is a rush happening around semantic layers, context layers, and knowledge graphs for enterprise AI. Today, it seems every major data infrastructure vendor is shipping tooling for it, all designed to make AI understand your business and create a living map of what your enterprise knows. This is important work, and the progress has been remarkable. Anyone working on this problem today is building on what these vendors have already done. But none of these tools are closing the biggest gap, and it is the most important one.

Where does business context actually live?

Context lives in data warehouses, databases, document stores, spreadsheets, Confluence pages, SharePoint folders, and legacy systems that are scattered across the organization. Tooling can crawl all of that, but the most valuable, most nuanced, and most decision-critical context lives somewhere it cannot reach. It lives in the heads of the subject matter experts in your business.

These are the people who know why revenue recognition works differently for that one product line versus another. The operations manager who understands the seasonal patterns that break naive aggregations, the compliance officer who can tell you which data fields carry regulatory constraints that are not written down anywhere, and the data architect who intimately understands that two tables with nearly identical schemas serve completely different business purposes because of a migration decision made four years ago.

In these examples, and in the many more that exist in every business, this isn't metadata or documentation. This is tribal domain knowledge, and it is the single most important input to any semantic layer that claims to represent business truth.

A semantic layer provides definitions, delivering one governed definition to every BI tool and AI agent, with consistent answers at query time. But these definitions aren't written by the semantic layer. They usually come from the data team writing YAML, or are imported back from existing BI tools. Whatever the case, the layer can only be as good as the business context of whoever authored it.

The hard part isn't the code

The industry has responded by implementing developer-centric approaches that rely on coding assistants and copilots to help data engineers write better YAML, SQL, and transformation logic. These approaches are valuable, but they assume the hard part is writing the code, when in fact it's capturing what the business actually means by each number before anyone writes a line of code.

A data engineer can write a perfect dbt (data build tool) model but if the true meaning behind it was never properly captured, if the grain of the fact table was assumed instead of validated, if the metric definition was borrowed from a dashboard built on a misunderstanding, then that model is precisely wrong. The code is clean, and the logic is sound, but the business answer is incorrect.

Until semantic layers capture what subject matter experts know, AI will keep giving answers that are well built and still wrong.

Getting it right requires expertise across the board. On the technical side, this includes data architects, security teams, and IT policy makers, all of whom understand access controls, data sensitivity, and the architectural decisions that shape what a model can represent. On the business side are your department heads, process owners, and domain specialists who know what happens in operational reality when an order gets flagged, a payment gets reversed, or a customer lands in a specific segment. Not what the column name says. Not what the documentation claims. Both groups need to participate. These are your experts, yet today's tools ask both groups to put what they know into YAML or SQL. Your company's security policy and business rules shouldn't depend on someone translating them into code.

Build forward from what experts know

Most semantic layer tools work backward, extracting meaning from dashboards, query history, and dbt projects that already exist. This can be helpful if you're looking to document what you have, but it doesn't give you what you need now.

Thus, when a business unit has a new reporting requirement, a regulatory change demands new metrics, or a strategic initiative needs a data product that does not exist yet, there is no query history and no dashboard to reverse-engineer.

The right approach is forward engineering. Here, the process starts with business requirements as defined by human experts and then builds forward into production. With this model, AI interviews the expert, captures what they know, reconciles it against the actual data, and translates it into business logic, transformation code, and validation rules. The output is governed code your existing semantic layer can serve. The expert never writes a line of YAML.

With this forward model, human experts drive the meaning while AI handles the speed, scale, and mechanical translation into infrastructure.

The context layer for enterprise AI is not a technology problem. It is a knowledge capture problem. The knowledge lives in documents, databases, processes, and people. We have built great tools for all of them, but only for people who can write code. Most of the people who hold the knowledge cannot.

The views and opinions expressed in this article are those of the author and do not necessarily reflect those of CDOTrends. Image credit: iStockphoto/WANAN YOSSINGKUM