Semantic Engineering: the new discipline behind trustworthy enterprise AI
2026 will be the year data and business analysts become semantic engineers
Walk into almost any large company right now and you will hear the same three things:
“We have an AI strategy.”
“We have a modern data stack.”
“Our AI still gives answers we do not fully trust.”
Models are powerful. Warehouses are mature. Yet when AI meets real enterprise complexity, you still see:
Confident but inconsistent answers
Agents that cannot safely take action
People arguing over which version of a metric is “right”
The missing piece is not more dashboards or another LLM.
The missing piece is meaning.
In 2026, I think we will finally name and formalize the discipline that owns this problem:
Semantic Engineering
The practice of turning a company’s business and data knowledge into semantic models that AI can safely understand, reason over, and act on.
And the people who will lead it are not “AI gurus”.
They are the data and business analysts who already know how the business actually works.
Much like dbt brought to the world the Analytics Engineers, we will now see Semantic Engineers.
Why semantics are now the bottleneck
Every large enterprise is racing to embed AI into how work gets done, from decision making and reporting to automated workflows and agents.
Very quickly they hit the same hard limit:
AI cannot deliver value unless it understands your data and your business logic.
Today that understanding is scattered:
Metric definitions are duplicated across tools
Business rules are buried in SQL, docs, and tickets
Edge cases live only in people’s heads
Governance rules change faster than reports do
Humans can work around this with context and memory.
AI cannot. When AI does not understand what a number means, it guesses.
At small scale you can patch this with ad hoc prompts, manual reviews, and heroic analysts.
At enterprise scale, it breaks.
Semantic Engineering is about treating that understanding as infrastructure, not as a side effect of dashboards or code.
The Semantic Models Lifecycle
If Semantic Engineering is a discipline, it needs a lifecycle.
At Solid we think about it as a five step loop. The slide you saw at the top is the visual version. Here is the narrative version.
1. Auto generated semantic models
You do not start from a blank page.
Your warehouse, BI tools, query logs, and documentation already contain a lot of implicit structure:
Which tables are used together
Which metrics people care about
How teams slice and dice the same concepts
Tools like Solid can now mine this “digital exhaust” and generate an initial semantic model in minutes instead of months:
Core entities and how they relate
Frequently used metrics
Common joins and filters
Think of this as raw material for Semantic Engineers. It is noisy, but it reflects reality.
For a deeper dive into how this works, we will be publishing more technical details in a follow up piece. If you enjoy that kind of thing, you might also like our earlier post “The Ghost in the Machine: How Solid drastically accelerates semantic model generation”.
2. Fine tune models
Generation gets you a draft. Semantic Engineers make it true.
This is where data and business analysts bring their knowledge of the organization:
Rename metrics and entities to match the language people actually use
Merge or split metrics that should not be separate in practice
Add rules like “exclude test accounts” or “include only paying customers”
Capture special cases: trial periods, multi currency revenue, regional exceptions
If you have read “Behind the scenes: how we think about semantic model generation” you will know how much nuance hides here. This step turns an auto generated graph into a faithful map of the business.
3. Test, validate, and publish
Once the model looks right, you still have to prove it.
Semantic Engineers treat semantic models like code:
Regression tests for metrics across dimensions
Comparisons against trusted reports
Spot checks with domain experts
Clear promotion steps from draft to “published” models
Only then do those models become available to AI experiences: chat with data, copilots in tools, operational workflows, or agents that take actions.
This is also where governance shows up. In “The Two Souls of a Semantic Layer: A Tale of Governance and Insight” we talk about how you need both: freedom to explore and strong guarantees when machines act.
4. Automatic updates
The business does not stand still. Neither can your semantics.
New products launch. Regions open and close. Pricing plans change. Regulations appear. If every change requires manually hunting through SQL and dashboards, the semantic model will always lag behind reality.
In a semantic engineering approach:
The platform notices that queries and schemas are changing
It suggests updates to the semantic model
Semantic Engineers review, adjust, and approve
The goal is simple: AI should always reflect how the business works today, not last year.
5. Optimize from real usage
Once AI is live, you finally see the sharp edges.
Semantic Engineers watch how humans and agents actually use the models:
Which questions appear over and over
Where AI is uncertain or inconsistent
Which workflows require human override
Where adoption stalls because answers are confusing
Real usage becomes a feedback loop that continuously improves the model.
We talked in the past about how much you can learn by watching what people do when they are not excited to use your AI. Semantic Engineering gives you a concrete way to respond: update the semantics so the next interaction is better.
Who are Semantic Engineers in practice?
The interesting thing is that you probably already employ Semantic Engineers. You just do not call them that yet.
They are:
The analyst everyone pings when numbers do not match
The finance lead who can explain exactly how “ARR” differs between sales, finance, and product
The operations manager who knows every exception in the customer lifecycle
The analytics engineer who keeps dbt models aligned with reality
Today these people are often trapped in reactive work:
Explaining the same metric definition over and over
Fixing broken dashboards
Translating between teams that all use the same words differently
Semantic Engineering gives them a new mandate:
Your job is to teach AI how the business works.
Your primary artifact is a living semantic model, not just a report.
Your success metric is how reliable and scalable AI becomes for everyone else.
You do not need to hire an entirely new team to start. You need to give your existing experts a name for the work they are already doing and better tools to do it.
Why this happens in 2026
Why am I confident that Semantic Engineering will emerge as a real discipline this year?
A few reasons.
GenAI has moved from novelty to expectation.
Two years ago people were still experimenting with “chat with my data”. In 2026 many executives expect AI to show up in their core workflows. Expectations are higher. Tolerance for inconsistent answers is lower.Data teams are feeling the strain.
In “Stop saying ‘Garbage In, Garbage Out’, no one cares” we wrote about how data leaders are asked to both “fix everything” and “ship AI” at the same time. Semantic Engineering is a way to focus on the thin layer that actually unlocks AI value instead of boiling the ocean.Vendors have caught up on infrastructure.
Warehouses, vector databases, orchestration, and LLMs are now mature enough that the new bottleneck is not plumbing. It is knowledge capture.A clear lifecycle is emerging.
The five step Semantic Models Lifecycle gives teams a concrete process to follow: generate, fine tune, test, keep up to date, and optimize from usage. Once there is a shared pattern, a named role tends to follow.The industry is already talking about it.
Leaders like Snowflake and Databricks are investing heavily in AI copilots that depend on semantic understanding. Folks like Tristan Handy at dbt Labs have written about how AI will transform BI and why semantics sit at the center of that shift. Semantic Engineering is the natural organizing principle for this movement.
How to start a Semantic Engineering practice in your company
If this sounds like a big change, it does not have to start big.
Here is a simple playbook you can run in the first quarter of 2026.
Pick one high value domain.
For example: renewals, claims processing, patient onboarding, field service, or supply chain exceptions. Do not start with “the entire company”.Nominate one or two Semantic Engineers.
Pick people who already act as translators between data and business. Give them explicit ownership of the semantic model for this domain.Generate a first model from reality.
Use your existing tools, query logs, and BI assets to create an initial semantic model. If you are using Solid, this is where the auto generated model appears almost instantly.Walk through the lifecycle.
Fine tune the model with real business rules
Validate against trusted numbers and experts
Publish to one AI experience, for one set of users
Instrument and iterate.
Watch how people use it. Where do they hesitate? Where do they stop trusting the answer? Feed that back into the model.Write down the playbook.
Document what worked and what did not. The next domain will be faster.
By the time you have done this for two or three domains, you will have a small Semantic Engineering practice in place, even if nobody has changed their job titles yet.
Closing thought
Ten years ago, “analytics engineer” was not a common title.
Today it is hard to imagine a modern data team without one.
I am confident that in a few years we will say the same thing about Semantic Engineers.
As AI moves from demos to the messy reality of enterprise operations, the winning organizations will be the ones that treat business meaning as a first class system. They will:
Capture it explicitly in semantic models
Keep it continuously aligned with the business
Put it to work safely through AI agents, copilots, and workflows
That is what Semantic Engineering is about.
And that is the discipline we expect to see emerge, loudly and clearly, in 2026.