Semantic layers are one model of the business

I was a huge fan of Looker. Then of dbt. Semantic layers after that.

The promise was simple and important: define business logic once, then reuse it. Stop rebuilding revenue in every dashboard. Stop asking each analyst to work out which join path is safe. Give people a consistent way to ask questions about customers, orders, churn, or average handling time.

Semantic layers are very good at this. They describe entities, dimensions, measures, and the joins between them. They turn a warehouse full of tables into something closer to the language of the business.

That solves a real class of problem: how do we calculate and explore the same things consistently?

But organisations use data to solve other classes of problem too - often harder ones, and often the ones that create a material advantage if you can solve them.

They need to know whether a customer is eligible for a product, not only how many eligible customers there were last month. They need to understand what will be affected if a piece of infrastructure goes offline. They need to trace how people, accounts, devices, and payments are connected when investigating fraud. They need to decide which interventions are possible at a particular point in a customer journey, not only report the conversion rate afterwards.

Those questions depend on more than metrics and joins. They depend on states, relationships, rules, constraints, responsibilities, and possible actions.

This does not make the semantic layer a failed ontology or an incomplete digital twin. It was designed for a different job. But it does raise a question: what other representations of the business exist, and why do they sit so far away from everyday analytics engineering?

Other ways to represent a business

Three ideas from adjacent fields are useful here. The terminology can make them sound more exotic than they are.

An ontology describes the concepts in a domain and the relationships that are allowed between them.

A database schema might tell you that customer_id joins to orders.customer_id. An ontology asks what a customer is: a person, an account, a legal entity, a billing relationship, or several of those in different contexts. It might describe the states a contract can enter, which party can hold which role, or which products can be offered under which conditions.

A knowledge graph records instances of those concepts and connects them.

Instead of only knowing that two tables can be joined, you can represent that Alice is the billing contact for Account X, Account X belongs to Parent Company Y, Parent Company Y is covered by Contract Z, and renewal risk on that contract is owned by Team A. The relationships are part of the data, not something every query has to reconstruct.

A digital twin represents the state and behaviour of something in the real world.

That might be a power network, a fleet of vehicles, or a manufacturing process. The useful definition is not "a 3D model" or "a very impressive dashboard". It is a model kept close enough to reality that you can inspect its current state and reason about what might happen if something changes.

These ideas overlap, but they are not interchangeable. An ontology can provide the vocabulary for a knowledge graph. A graph can provide some of the structure for a twin. A twin also needs state, time, rules, and some account of how the system behaves.

Nor do they replace the warehouse. Warehouses remain excellent at events, history, and aggregation: what happened, how many times, over what period, grouped by what. These other representations become useful when the shape of the problem is itself important.

Sometimes the structure is the question

I have seen this most clearly in domains where the mismatch is hard to ignore.

At Railsr, fraud investigations depended on how accounts, people, devices, and payments were connected. The interesting signal was often a neighbourhood or path: who is linked to whom, through what, how recently, and how unusually. The underlying events still belonged in tables, but I found myself using recursive CTEs to answer questions that would have been more naturally expressed as graph queries.

On a energy network project, outage planning required a model of the power network. Historical reporting could tell us what had happened before. It could not, by itself, tell us what else would be affected if an asset were taken offline, what constraint that would create, or which sequence of outages was feasible. Those questions required a representation of the network against which possible changes could be tested.

Those are obvious graph and twin examples. But the same distinction appears in more ordinary analytical work.

With a telco client, the commercial question sounded like churn. A semantic layer could define subscribers, contract renewals, and customers lost. That answered some useful questions. It was not enough once you looked at what actually happened at the end of a fixed contract: if the customer did not sign a renewal, they did not necessarily leave. They often moved onto a rolling monthly tariff. "Churn or not" was the wrong shape. The useful model was closer to a state machine - fixed term, approaching end of contract, renewed, rolling monthly, genuinely left - plus the rules for which transitions were possible, which interventions made sense in each state, and who owned them.

You can store all of that in relational tables. The issue is not whether SQL is capable of representing it. The issue is whether the shared model makes those relationships and rules explicit, or whether every analysis has to reconstruct them from columns, joins, code, documentation, and conversations.

Analytics engineers already do the discovery work

This is the part that interests me most.

Analytics engineers already uncover much of the knowledge these richer representations require. We learn that "customer" means one thing to Finance and another to Product. We discover that a status field does not contain all the states the process can really enter. We find the join that is technically valid but semantically wrong. We learn which team can change an outcome, which rule has an exception, and which definition is only appropriate for one decision.

That work happens while building marts, reviewing metrics, debugging pipelines, and working through questions with domain experts. Domain experts remain the source of truth for how the organisation operates. But AEs are already doing the discovery and framing required to turn that knowledge into something reusable. They are the natural candidates to take on capturing more of it - just as they became the people who made metrics and joins shared rather than tribal.

Today that understanding ends up distributed across model names, SQL comments, YAML, pull requests, documentation, Slack threads, and people's heads. Some of it becomes a metric definition. Some becomes a test or a data contract. Some belongs in a catalog, a process model, or an operational system. Much of it never finds a durable form at all.

The problem is not that every piece of context should be forced into one grand ontology. Different representations exist for good reasons. A metric definition, a process diagram, a knowledge graph, and a simulation model serve different users and different questions. Trying to make one model describe an entire company would create its own problems: specialist bottlenecks, false consistency, and another source of truth to keep in sync.

But complete separation has a cost too. The meaning of "customer" is authored again in the warehouse, semantic layer, CRM, policy rules, ML features, and perhaps a graph. The relationship between a contract and an account is rediscovered by each team. A business rule may exist once in documentation, once in application code, and once more as a filter in an analytical model.

The representations are different. The understanding underneath them often is not.

One point on a spectrum

Perhaps a semantic layer is best understood as one point on a spectrum of business modelling.

In some cases, we describe how data should be aggregated: measures, dimensions, and metrics.

In others, we describe concepts and relationships: what the important things are and how they connect.

Elsewhere, we describe state, rules, and possible transitions: what can happen, what is allowed, and what can be changed.

And in some domains, we build a model against which we can test possible futures before acting on the real system.

This is not an argument against descriptive work. Knowing what happened remains foundational. Being able to predict or prescribe does not make last month's revenue less important, and most valuable analytics engineering still lives in that territory. More modelling is not automatically better. If the question is "what was revenue last month?", a governed metric is probably exactly the right abstraction. A digital twin would be absurd. Richer representations earn their cost only when the question requires them.

But treating these as points on a spectrum changes the design question. Instead of asking every tool to become the new home of business meaning, we might ask which parts of that meaning can be shared and which representations should be derived for particular uses.

Could a semantic layer be compiled from a broader model of business concepts and relationships? Could analytical findings contribute back to that model rather than disappearing into the next dashboard? Could rules used by operational systems and definitions used by analysts refer to the same underlying concepts without pretending they are the same artefact?

Why AI makes this more pressing

Giving an AI access to governed metrics helps it calculate consistently. It does not tell it which actions are possible, which relationships matter, why a definition varies by context, or who has authority to make a change. If we want AI to do more than generate SQL and describe charts, it needs access to more of the organisation's operating model.

It is tempting to treat that as a retrieval problem: put more of the organisation into Confluence, Slack history, or meeting notes, and let the model clarify ambiguities in conversation. That can work for one person, once. Then the next person - or the same person next week - has to do it again. Adding more documentation is better than nothing. It is not a substitute for structured metadata. This is why text-to-semantic-layer systems outperform text-to-SQL so consistently: joins and canonical metrics are not left to luck each time. The model can generate against something already agreed.

AI may also be part of how this becomes practical. A richer model of concepts, states, and rules has historically been expensive to build and keep honest. If AI can help propose structure, surface inconsistencies, and draft updates from the discovery work AEs already do, managing that model becomes more feasible than the ontology programmes of the past.

Where the idea might go next

I do not think the answer is that every analytics engineer should learn Neo4j, or that every company needs an ontology programme. It may not even require a graph database.

The more immediate observation is simpler: analytics engineering has become very good at making calculations reusable, while much of the understanding needed to use those calculations remains scattered.

Semantic layers showed the value of taking one part of that understanding and giving it somewhere durable to go.

Why should we assume metrics and joins are where that idea ends?