Semantic Modeling: Teaching Data Systems How the Business Works

Representing business meaning in data systems is not a new problem. What changed is the number of things consuming that meaning. For most of the discipline's history the audience was analysts and BI tools. Now dashboards, notebooks, data apps, APIs, natural language interfaces, and AI agents all interpret the same underlying data, and they interpret it without the informal repair mechanisms humans rely on. An analyst who is unsure what a field means can ask in Slack. An agent is expected to answer in seconds.

Coginiti CTO Matthew Mullins spoke with Christina Salmi, Managing Director of Data Strategy at Analytics8, about what semantic modeling actually involves in practice — and about the parts of it that no technology has removed.

Context, model, and layer are three different things

Salmi opens client engagements by asking what people mean by the term, because the answers differ enough to derail the conversation otherwise. She separates three ideas.

Context. The additional business information that makes collected data more useful — the surrounding knowledge that is not in the schema.

The model. A semantic model organizes data according to business relationships rather than physical storage: a conceptual account of how things relate to each other.

The layer. A semantic layer is how that model gets carried out — the machinery that translates business terms into something technical, traditionally SQL, consistently.

Most arguments about the semantic layer turn out to be arguments about which of the three is under discussion. Mullins calls the surrounding noise "semantic washing" — nearly every vendor now has a semantic something, which makes the term useless until it is unpacked.

Why modeling became a lost art

Neither participant treats dimensional modeling as new. The techniques date to the 1960s, matured through Inmon and Kimball in the 1990s, and Data Vault arrived later. The concepts have been stable for decades. The practitioners have not.

Salmi attributes the decline to two forces. Each new technology arrives with an implicit promise that modeling is no longer necessary. And modeling requires an uncomfortable combination of skills: it is not only technical work, but talking to the business, understanding its processes, and using that understanding to decide how data should be organized. Engineers who prefer to stay behind the keyboard have little reason to move toward it.

Mullins adds a structural cause. Schema-on-read and cheap storage shifted attention from modeling data to moving it, and the industry compressed a set of distinct roles — data architect, data modeler, ETL developer — into the single title of data engineer. The modeling work did not get reassigned. It stopped being anybody's job.

What follows is predictable: data arrives at its destination, the harder problems are deferred, and they are mostly never solved.

Twenty-nine definitions of "customer"

Mullins described an engagement at a large grocer where analysis of query history surfaced twenty-nine distinct definitions of a customer, none of which the organization knew it had. That is the mundane explanation for why two analysts produce different numbers for the same question.

Salmi's reframing of this problem is the most useful idea in the conversation. The goal is not to arrive at one definition. It is to make sure there are no definitions operating invisibly.

Most organizations have corporate-level metrics agreed across departments, and individual domains that need legitimate variations of them. A customer count for a customer service decision is reasonably different from a customer count for a marketing campaign. Both are valid. The requirement is that the variation is intentional, documented, and attributable — not an accident discovered later in a reconciliation meeting.

Historically the tools for expressing that were thin: documentation and naming conventions. Systems that can carry context alongside data allow something better, where the question itself indicates which definition applies.

Ownership is the part technology does not solve

Asked who should own the semantic model, Salmi is unambiguous about the definitions: the business owns them. The common failure is that everything gets handed to IT, which then maintains definitions with no live connection to the people whose meaning they encode.

Whatever the maturity of an organization's governance, the minimum viable arrangement is assigning ownership of each business definition, so that changes propagate in both directions. When a source system changes in a way that affects a metric, someone knows whom to ask. When the business decides to count active customers differently, there is a path for that decision to reach the people implementing it.

Salmi is explicit that the mechanism can vary — organizations should choose what is sustainable at their current maturity — but that assigning stewardship cannot wait for a formal program to exist.

Versioning semantics like software

Mullins raised the lifecycle question: semantic definitions ought to be versioned, tested, reviewed, and promoted the way software is, particularly for organizations with regulatory obligations that require explaining how a number was calculated three years ago.

Salmi's answer is that this has historically been the weak point. Teams would snapshot a dashboard monthly for audit purposes, but not the definition behind it — which makes the archived number unexplainable the moment the definition changes. Versioning the semantic layer itself closes that gap, and it is a relatively recent capability.

Where the semantic layer sits

An audience question asked where semantics belong relative to bronze, silver, and gold.

Salmi treats the medallion names as the current labels for a long-standing idea — persistent staging, transformation, presentation — where the point is being intentional about what happens to data in each layer and what consumers can expect from it. Dimensional modeling has a natural home in the gold layer for data that is physically stored there.

But the semantic layer does not have to be confined to it. Her argument runs through the history: the industry swung from chaotic inconsistency, to consolidating everything in a warehouse, to abandoning that as unrealistic and loading everything into lakes, back to a middle position. Modeling is worth the effort, and it will only ever cover a subset of the data. The rest still has to be available, with expectations set clearly about what has been curated and what has not.

A semantic layer that can pull from multiple sources and multiple layers lets you attach the context you do have to data that never made it through full curation. On where business logic should live — transformation or semantic layer — she declines to give a universal answer: it depends on organizational size and maturity, and it should sit wherever the team can actually sustain it while keeping the connection to the business intact.

Mullins made the case for the semantic layer as an abstraction that spans systems rather than one that sits on top of a single warehouse. His shorthand: every enterprise has three data warehouses — the one they are on, the one they are moving to, and the one they inherited in an acquisition. Coginiti's largest customer spans roughly twenty data platforms. Maintaining semantics separately in each is not a workable position.

AI-generated models and the Rapid Marts precedent

Databricks recently released forty industry models, all agent-generated. Industry models themselves are not new; Teradata built a business on them and others followed.

Salmi has seen this before. Early in her career she worked with SAP Rapid Marts — prepackaged, domain-specific models with extensive documentation, encoding how to make sense of a notoriously complex source system. They were accurate, and they were overwhelming. She reaches, carefully, for a modern comparison: the precursor to AI slop, not because the output was wrong, but because the business was never involved in producing it.

The reason they underdelivered is the reason the AI-generated versions will. Nobody runs a vanilla ERP implementation. Every organization uses fields slightly differently. The prepackaged logic for combining twenty source tables into one dimension has real value — and then the actual work begins, which is finding out what the business means by that field.

Mullins framed it as a Pareto split: these accelerators get you an eighty percent that is directionally right, and the remaining twenty percent is precisely what makes the business distinctive. Salmi sharpened it further — the useful eighty-twenty is not of all the data you could model, but of the data the business actually cares about.

Both use agents as accelerators rather than authors. Coginiti's Forge agent proposes structure from physical tables on the assumption that a person will review it. Analytics8 uses agents to scan metadata for PII tagging, naming convention drift, and classification gaps, then iterates — treating the output as material that makes the conversation with the business more productive, not as a finished model.

Where to start

Salmi's advice for organizations without a modeling discipline is to start incrementally, and she is direct that the design-big, build-big instinct is what produces the two-year initiative that ships nothing and sits on a shelf.

Interview a couple of stakeholders rather than everyone. Find a use case where the value is legible. Make the change tied to that use case, and use the result to build the credibility that makes the next piece easier.

On reading, she points to the 1990s canon — The Data Warehouse Toolkit and The Data Warehouse Lifecycle Toolkit. Some of it is dated, mostly the parts concerned with performance limits that technology has since removed. The goals it sets out for building a warehouse, though, survive the substitution: cross out "data warehouse" and they read as the goals for anything you build with data for analytics. Its chapters are organized by industry, which makes it useful for seeing the same patterns recur in different shapes.

What to watch for

Asked how a manager can tell that a semantic modeling effort is going wrong, Salmi named three signals.

Overbuilding. For any work in flight, the team should be able to point to the business use case it serves. "We're modeling everything coming out of this source system" is the warning.

No clear owner. If nobody can say who decides what gets modeled or which definition wins, that gap needs closing immediately. A formal governance program is not a prerequisite; assigning stewards is.

Solving an architecture problem instead of a business problem. This one is harder to spot and more sympathetic — a team on aging infrastructure has genuine reasons to want better tools. Technology changes are often correct. They still have to be expressed in terms of what the business gets: shorter turnaround on new requests, analysis that was not previously possible. That translation is also what tells you which piece to build first.

Watch the full conversation

The recording runs above. For related reading, see our post on what happens when the model eats the stack, which covers the research finding that semantic and environmental errors become a larger share of agent failures as models improve, and our guide to semantic modeling.