Five Things Enterprise Architects Get Wrong About Semantic Modelling — and How to Fix Them

I recently ran a live demo on proactive semantic modelling for over 800 data professionals across EMEA. The questions that came in during the session were some of the sharpest I’ve seen — and they pointed directly at five architectural mistakes I see teams repeat constantly.

This is my attempt to give those questions the long-form answer they deserved.

Semantic modelling has had something of a renaissance. We all surely understand that attaching semantics i.e. meaning to data greatly contributes to common understanding of that data. But, the rise of agentic AI systems has finally made the question of “what does this data actually mean?” acutely urgent in ways it wasn’t when a human was in the query loop. A human analyst can resolve ambiguity on the fly by applying their specific domain knowledge. An AI agent cannot. It will pick an interpretation, run with it, and confidently return a wrong answer or at best, an incomplete answer.

The semantic layer is how you prevent that. It’s the governed, machine-readable definition of what your data means: how metrics are calculated, how dimensions relate, what terms like “active customer” or “net revenue” mean in your specific business context. Without it, every AI system you build is working from an implicit, unverified interpretation of your data.

If we’re ever disappointed in the results of AI reasoning, it’s because we realise we’re bigger experts than AI on the topic and that we’d do a much better job. And the root cause is its lack of understanding the underlying data i.e. not having enough context.

The challenge is that building a semantic layer is not a one-time project. It’s a discipline. It’s a muscle to be built and maintained. But most organisations approach it in ways that create more fragility than they solve. Here are the five patterns I see most often — and what to do instead.

Mistake 1: Assuming you need to start from scratch

The question that surfaced this: “What’s the difference between pure dimensional modelling and Snowflake semantic views? Can we reverse-engineer our existing model? How do we integrate with Erwin/IBM IDA? Does SqlDBM generate dbt SQL or just the YAML?”

Very obviously, every one of these questions came from teams that already have something. A dimensional model. A dbt project. A BI semantic layer. Years of business logic encoded in transformations, views, and documentation. And every question was really asking the same thing: do I have to throw this away?

The architectural reality: Your existing assets are not the problem. Fragmentation is the problem. Most enterprises have semantics in four places simultaneously — the warehouse layer (dimensional models, views), the transformation layer (dbt metric definitions, staging models), the BI layer (Power BI datasets, Tableau data sources), and tribal knowledge in spreadsheets and wikis. None of these talk to each other. When an AI agent asks a question, it hits one of these layers and ignores the others, producing an answer that is locally consistent but globally wrong.

What good looks like: Rather than replacing, consolidate. Treat your existing dimensional model as the structural foundation — it already encodes entity relationships and grain definitions that are hard to rebuild. Treat your dbt models as the transformation and metric logic layer. Then build your semantic model on top of these, referencing them rather than redefining them. Use reverse-engineering capabilities where they exist to pull existing definitions into your semantic tooling, review them, and formalise them. LLM models are surprisingly good at reverse-engineering.

The target architecture is a single semantic layer that acts as the canonical reference for all consumers — BI tools, AI agents, APIs — with your warehouse and transformation layers as implementation details beneath it, not competing semantic surfaces.

The anti-pattern to avoid: Building a parallel semantic model from scratch because it feels cleaner. It will be cleaner — for about three months. Then it will diverge from the warehouse, the BI tool will still be using its own definitions, and you’ll have three semantic surfaces instead of one.

Mistake 2: Treating semantic modelling as an engineering problem

The question that surfaced this: “Business experts hold the knowledge — is there a suitable interface for them to author and manage the semantic model, or does it always have to go through a data engineer?” And: “Are Business Glossary terms supported? Can enterprise-wide definitions be embedded?”

These questions reveal a fundamental misconception that is extremely common: that the semantic model is the data team’s responsibility to build and maintain. It isn’t. Or rather — it can’t be, at scale.

The architectural reality: The data team has the technical capability to build a semantic model. But they don’t have the domain authority (domain knowledge) to define what “churn,” “active account,” or “net revenue” means for the business. For your business, to be precise. That authority lives with the people who make decisions based on those numbers — finance, commercial, product, operations. When the data team makes these definitions alone, they make implicit choices that the business either doesn’t know about or actively disagrees with. Those disagreements surface later, usually at the worst possible moment (on a Monday morning when the board is looking at the financial reports).

What good looks like: Design your semantic governance model around two distinct roles. The semantic architect (data team) is responsible for the technical structure: how dimensions and metrics are implemented, how the model connects to the warehouse, how it is tested and deployed. The semantic steward (business domain owner) is responsible for the definition: what the metric means, what its boundaries are, what edge cases are excluded, and who has authority to change it.

This separation requires tooling that exposes the definitional layer to non-engineers — ideally through an interface that lets a business analyst review, annotate, or propose changes to a metric definition without touching the underlying YAML or SQL. It also requires a review and approval workflow: a proposed change to a core business definition should go through the same kind of review process as a change to a financial report.

Embedding your Business Glossary into the semantic model — rather than maintaining it as a separate documentation artifact — is the right architectural choice. It creates a single point of truth that both humans and AI systems reference, rather than a documentation layer that gradually falls behind the implementation.

If you already have a Business Glossary, LLMs are also good here for reverse engineering it into elements of a semantic model.

The anti-pattern to avoid: Documenting semantic definitions in Confluence or a wiki that lives next to, but separate from, the technical model. This always diverges. Documentation is written once and not maintained. The semantic model, if governed properly, is maintained because it breaks things when it’s wrong.

Mistake 3: Building a monolithic central model

The question that surfaced this: “How can decentralised teams extend a central semantic model without giving them broad access? We want a central foundation that teams can enhance with additional dimensions.”

This is the most common architectural mistake at scale, and it comes from a reasonable instinct: you want consistency, so you build centrally. But a monolithic central semantic model becomes a bottleneck. Domain teams can’t extend it without going through the central team. The central team becomes a queue. Changes slow down. Domain teams start building their own parallel models in the BI tool or in ad-hoc SQL views, and you’re back to four competing semantic surfaces.

The architectural reality: We don’t need to look far. Organisations have already adopted a decentralised data governance and we can now extend that to data semantics. The solution is a hub-and-spoke semantic architecture, modelled on how mature data mesh organisations structure ownership. The central (hub) model defines core entities and metrics that must be consistent across the organisation — customer, account, revenue, date. These definitions are owned by the platform team, versioned carefully, and changed through a governed process. Domain teams (spokes) extend this core model with their own dimensions, metrics, and relationships — but cannot modify the core definitions.

What good looks like: Design your semantic layer with an explicit tiering model:

• Tier 1 — Core: Universal entities and metrics. Owned by the platform team. Changes require cross-functional review. Examples: Customer, Account, Revenue, Date, Employee.
• Tier 2 — Domain: Domain-specific extensions of core entities. Owned by domain teams. Changes require domain review. Examples: Marketing Campaign (extends Account), Product SKU (extends Revenue).
• Tier 3 — Exploratory: Draft or experimental definitions. Owned by individual teams. Not used in production AI systems until promoted to Tier 2.

Access control follows this tiering: domain teams have write access to Tier 2 and 3 within their domain, read access to Tier 1, and no write access to other domains’ Tier 2. This is implementable with role-based access in any modern semantic modelling tool.

The critical design principle: extensions must reference core entities, not redefine them. A domain team can add attributes to the Customer entity; they cannot change what “Customer” means.

The anti-pattern to avoid: Granting broad write access to the central model in the name of velocity. One team’s “helpful shortcut” metric definition will conflict with another team’s definition within six months, and you’ll spend weeks reconciling them.

Mistake 4: Not deciding where context lives

The question that surfaced this: “What’s your view on providing context via Skills containing knowledge versus expanding the data model to include additional definitions and context?”

This question is underrated. Most teams don’t make this architectural choice consciously — they default to whichever mechanism their AI tooling makes easiest, and they pay for it later. As AI systems mature and you have multiple agents, multiple use cases, and multiple teams building on top of your data, the question of where context lives becomes one of the most consequential architectural decisions you’ll make.

The architectural reality: There are three places context can live in an AI system: in the semantic model (structured, versioned, governed), in retrieval artifacts like skills and knowledge bases (flexible, searchable, less structured), and in system prompts (immediate, fragile, unversioned). Most teams use all three without a clear policy for which is appropriate when.

What good looks like: Apply this decision framework:

The test for whether something belongs in the semantic model is: should this definition be the same regardless of which AI agent, which BI tool, or which API endpoint is asking the question? If yes, it belongs in the semantic model. If it’s context that only makes sense for a specific interaction or agent, it belongs elsewhere.

The anti-pattern to avoid: Putting business metric definitions in system prompts because it’s faster. You end up with 12 agents, each with a slightly different definition of “active customer” in their system prompt, and no centralised way to update them when the business definition changes. You will not catch this until an agent gives a materially wrong answer to a consequential question.

Mistake 5: Treating the semantic model as a deliverable

The question that surfaced this: “If I build a semantic model on top of a table and then the table changes — will it automatically update, or will it drift?”

This is the question that separates teams that have actually operated a semantic model in production from teams that have only built one. The honest answer is: in most implementations, it will drift. Schema changes in the warehouse will silently break semantic model assumptions. New columns won’t automatically surface as available dimensions. Renamed fields will cause query failures in AI agents at runtime, not at build time. Business definitions will evolve without the model being updated.

Drift is the silent killer of semantic accuracy. And it’s almost always a process failure, not a technical one.

The architectural reality: A semantic model in production requires the same operational discipline as any other production system. That means:

1. Schema change detection. Your CI/CD pipeline should include a step that validates the semantic model against the current warehouse schema after any schema migration. Breaking changes (renamed columns, dropped tables, type changes) should fail the pipeline and require explicit semantic model updates before deployment.
2. Semantic model testing. Every metric and dimension in your semantic model should have a test: does this metric return a non-null result for the last 30 days? Does this dimension have fewer than N% null values? Does this join return the expected grain? These tests should run on a schedule, not just at deploy time, because data changes between deployments.
3. Definition versioning. Treat semantic model definitions like code. Use version control. Maintain a changelog. When a business definition changes, the old version should be preserved and the change should be traceable — so you can answer the question “why did this metric behave differently before and after March 1st?”
4. Ownership assignment. Every entity, metric, and dimension in the semantic model should have a named owner — a human being who is responsible for its accuracy and notified when tests fail or schema changes affect it. Without named ownership, maintenance tasks fall into a collective responsibility that nobody actually takes.
5. Deprecation process. Semantic models accumulate technical debt. Metrics that are no longer used, dimensions that have been superseded, definitions that reflect a business reality from two years ago — these need to be identified, communicated to consumers, and formally deprecated. An AI agent querying a deprecated metric is a liability.

What good looks like: If your semantic model is in production, you should be able to answer these questions on any given day: What changed in the last 30 days? Are all tests passing? Which metrics haven’t been queried in the last 90 days? Who owns each definition? What’s the current version?

If you can’t answer these, you’re not operating a semantic model — you’re hoping one is still accurate.

The anti-pattern to avoid: Treating semantic model maintenance as a project that runs alongside a data engineering initiative, then winds down when the initiative closes. The semantic model doesn’t end. It runs forever, or it becomes a liability.

Where to start

If you’re an enterprise architect looking at this list and feeling the weight of it, start here:

1. Inventory first. Before you build anything new, catalogue what you have: dimensional models, dbt metric definitions, BI semantic layers, any documented business glossary. The goal is to know where definitions currently live and which ones conflict.
2. Define the core. Pick five to ten metrics and entities that must be consistent everywhere — the ones that, if wrong, cause real business harm. Define them once, with named owners, in a governed layer. Don’t try to model everything on day one.
3. Choose your tooling for federability, not just power. The question isn’t which tool can build the most sophisticated semantic model. It’s which tool can be extended safely by distributed teams without centralised bottlenecks.
4. Build the operational wrapper from the start. Schema change detection, automated testing, and ownership assignment are not things you add later. They’re things you’ll never add if you don’t add them now.
5. Connect to AI as a forcing function. The pressure of AI reliability is the best organisational lever for finally getting semantic governance taken seriously. Use it.

The organisations that will build reliable AI aren’t the ones with the most sophisticated models. They’re the ones that treat semantics as infrastructure — built carefully, governed consistently, and operated like production systems.

The rest will spend their time debugging why the agent gave the wrong answer.

Want to see these principles applied in a live Snowflake environment? The on-demand recording covers the practical implementation — including how SqlDBM and Snowflake Semantic Views work together to address exactly these challenges.

Watch on demand → https://www.snowflake.com/en/webinars/demo/proactive-semantic-modelling-make-your-data-products-aiready-2026-05-20/