Your semantic layer just became your AI governance layer

Someone on your team asked an assistant for last quarter's revenue by region. Thirty seconds later they had a chart. It looked right. It went into a deck.

Someone else asked a slightly different question, in a slightly different way, and got a slightly different number. That went into a deck too.

Now two people are in a meeting quoting the same metric four percent apart, and the conversation stops being about the business and becomes about whose number is correct.

Nobody did anything wrong. Both answers were built from scratch, from whatever each assistant could work out on its own.

It is the spreadsheet problem again — the same question producing different answers depending on who asked it — except it now happens in seconds rather than weeks, and it arrives with a chart already attached.

The instinct is to slow it down. Lock the assistants out, put the requests back in a queue, wait for the data team. 

We think that is backwards. 

People have found a way of working that is genuinely faster, and they are not going to give it up because governance asked them to.

So rather than fight it, we rebuilt the thing they should be building from.

What actually changed is not the tooling. It is who is reading your model.

Semantic layers are not new, and Astrato has had one for years. Row-level security, warehouse UDFs, inline tables, joins with automatic suggestions, connections across Snowflake, BigQuery, Databricks, Redshift, PostgreSQL, ClickHouse, DuckDB and Athena — all of that already existed and all of it still works exactly as it did.

What changed is the traffic arriving at it. Three shifts, and each one breaks an assumption the old generation of semantic layers was built on.

The reader changed. A semantic layer used to serve a known set of dashboards, built by people who knew the model's quirks and worked around them without thinking. 

An AI assistant knows none of those quirks. It will ask anything, phrased any way, at any volume, and it will produce a confident, well-formatted answer whether or not your model can actually support the question. 

A gap in your model used to surface as a chart someone could not build. Now it surfaces as a plausible number nobody questions.

The writer changed. AI does not only query the model any more. It edits it — creates a measure, adjusts a join, renames a dimension. 

A model that an assistant can write to needs history, attribution, validation and a way back, or letting it near the model is indefensible. Version control is not a feature we added alongside the AI work. It is the precondition for the AI work.

The demand changed. Every new question wants a new measure. If changing the model is slow and frightening, the semantic layer quietly becomes the new queue — and people route around a queue. The logic you spent months centralising creeps back into individual dashboards, one workaround at a time.

Put together, those three shifts promote the semantic layer from a modelling convenience to a control surface. It is no longer just where definitions are kept. It is the thing standing between your organisation's data and every assistant now asking it questions.

That is a different job, and it needed a different editor.

The new AI-native Semantic Layer Editor is where your measures, dimensions and joins are defined, owned and verified — and it is the layer an AI assistant has to work through, whether that is Nash inside Astrato or Claude, ChatGPT, Codex or Snowflake CoCo connected from outside. 

Same definitions. Same permissions. Same answer, whoever asks.

This is a new editor, not an update to the old one. It is available to every Astrato customer today.

New: Version control

Change the model without holding your breath.

Here is the real reason semantic layers go stale. Not neglect — caution.

The model is shared. One edit to one measure changes what a room full of people are looking at, and until now there was no reliable way back. So the sensible move was to leave it alone. Definitions drifted out of date, people worked around them, and the centralised logic dispersed again.

The editor now keeps a full history of your semantic layer: what changed, when, and who changed it. There is no Save button, because there does not need to be one — your work is written as you go.

• Compare any two points in time. Open Versions and put an earlier version side by side with what you have now, with every difference sorted into tables, fields, joins, dimensions and measures.

• Roll back all of it, or just the part that broke. Take back an entire version, or tick the single definition that went wrong and restore only that.

• Go down to a single measure. Version history works at the level of individual semantic assets, so you can look at how one measure has evolved without reading the history of the whole model.

• Share a version with a colleague rather than describing a change in Slack and hoping it lands.

• Nothing is ever destroyed. A restore arrives as a new version on top of your history. The trail stays intact, and you can undo the undo.

Worth forming as a habit: name a version before anything risky — restructuring joins, renaming measures, a bulk edit. Named and published versions are the ones guaranteed to come back.

What this changes is not really a feature. It is a mood. When a bad edit costs four minutes instead of a week of apologies, teams start making the changes they have been putting off for months, and more than one person can safely own the model, because history shows exactly who did what.

Built-in validation & error handling:

Find out from your model, not from your CFO.

Most BI incidents are not dramatic failures. They are a quietly wrong number that reached a dashboard because nothing stopped it.

Three things now stop it.

• A broken model cannot be published. Beside Publish sits an issues count. While anything is unresolved, publishing is blocked and the button tells you exactly what is holding it up — missing fields and references, broken measures, incompatible data types. Publishing pushes your model to everyone using it, so the editor will not release one it knows is broken. Your work stays saved the whole time; a blocked publish costs you nothing, it simply waits.

• Astrato watches your warehouse for changes underneath you. It checks the tables, columns and functions your semantic layer actually uses, and flags missing fields, inconsistent data types and upstream schema changes as errors. A changed column type lands in a new draft rather than going live on its own. A missing table or column blocks publishing until you repair it.

• It never guesses. If Astrato cannot tell whether an object was removed or your credentials simply cannot see it, it says sources are unverified rather than inventing an answer. A model that is almost right is worse than one that is honestly uncertain.

And when something does break, repair is a redirect, not a rebuild. Point the broken table or field at its new source and your semantic names, along with every reference to them, stay intact. A rename upstream no longer forces a rebuild downstream.

Nobody's work gets overwritten either. If the live model was edited somewhere else, the editor notices, pauses automatic publishing and keeps both versions so you can compare and decide. Nothing is merged behind your back.

Saving is not publishing

This is the single idea to carry into everything else, so it is worth stating on its own.

Your work is safe in the editor long before anyone else sees it, and nothing reaches your workbooks until you publish. 

You choose how that happens: 

• Manual, to release a set of related changes as one coherent update; 
• Delayed, to publish once you stop editing; or 
• Instant, while you are experimenting alone.

Manual is the default, and it is the right choice for any model other people depend on.

MCP integration

Bring your own AI. Keep your own governance.

Connect Claude, ChatGPT, Codex or Snowflake CoCo straight to Astrato through our MCP connector and let it read your semantic layer, search it, create and edit measures, validate the model and query it — in the same capacity as Nash inside the product. It works on your behalf, with your permissions, on your organisation's data.

• You are not handing over a password. You sign in to Astrato yourself. The assistant receives a limited pass tied to your account that lists exactly what it may do: read semantic layers, edit drafts, create versions. You can withdraw it whenever you like.

• Every AI edit is a tracked edit. Anything an assistant changes lands in your working copy, appears in version history beside your own changes, and still has to clear validation before it can be published.

• Governed answers, not raw queries. Business questions are ready-made analytical questions over your model — "show sales amount by product category" — carrying the approved fields, ranked chart suggestions and sensible defaults. Applications and assistants call a question by its ID. They never build or send the underlying query.

The usual objection to AI touching the data model is that it is ungoverned. Here it inherits the same permissions, the same validation and the same audit trail as a person. An assistant cannot do anything you could not do yourself, and it cannot do it invisibly.

It also means you do not have to standardise your whole company on one assistant. One team on Claude and another on ChatGPT can both build against the same definitions and get the same numbers.

But no external AI needed — Nash is already inside the editor

Describe the change you want in plain language and have it made for you, steer it while it works, and keep the conversation attached to the semantic layer it belongs to.

Nash can:

• Build a full semantic layer from scratch by pointing it at your data source — dimensions, measures and joins included.
• Summarise the errors in your model and fix them for you.
• Run queries and analysis to answer a question directly, returning interactive charts you can open in the Data Explorer.

Nash works through exactly the same governed operations as any outside assistant. Its edits land in your working copy, appear in version history, and still have to clear validation before anything is published.

Why it matters: the bottleneck in most semantic layers is not knowing what the business needs. It is the queue of people who can express it in the model. This opens the queue without opening the governance.

The context an assistant actually needs

An AI assistant reasoning about a column called SALESAMOUNT is guessing. An assistant reading a measure called Monthly Sales, with its formula, a plain-English description of what it means and the lineage showing where it comes from, is not.

• ‍Business context lives in the model. Add descriptions and business meaning directly to semantic objects, so the semantic layer becomes a documented account of how your organisation understands its data — not just a collection of technical definitions. That context is available to your analysts and to every AI system working with the model.
• ‍Documentation writes itself. Generate human-readable documentation of your semantic layer and business context, summarising every semantic entity including the technical detail, and export it to Word, PDF or Markdown to share or upload to your company knowledge base.‍
• Lineage shows the chain. The semantic lineage view draws the dependencies between semantic assets, so you can follow any number back to the tables it rests on and see what a change will affect before you make it. It answers the question people actually ask in a meeting: where does this come from?

• And the model is easier to move around. Map View gained text search and richer annotations showing where fields are used as dimensions, measures or filters, and it now handles large catalogue models without slowing down.

The tab views for tables and fields, joins, measures and dimensions show semantic dependencies and version history, with faster search and grouping, and bulk deletion when you need it. The measure editor organises filters properly and can display measure logic as text or as SQL. And the Data Explorer lets you preview, visualise and explore your data — creating and editing measures and dimensions while you watch the results update, now with pivot tables, bar charts and line charts.

Your model is still yours

If the semantic layer is going to be the governance harness for everything your business builds, you cannot accept it being a black box.

• Snowflake Semantic Views can be imported, reused and extended across Astrato workbooks and Nash. If you have already modelled semantic views in Snowflake, build on them rather than recreating them by hand — the real cost of adopting a semantic layer is the migration, not the licence.

• Developer View gives you the code. Edit the underlying YAML or JSON structure of the semantic layer directly, with error handling in the code itself.

• And you can take the whole thing with you. Export your semantic layer to YAML, JSON or Apache Ossie, an open standard other tools can read. Most vendors answer the lock-in question with a promise. This answers it with a file.

Everything you have already modelled comes with you

None of this replaces what you have built. Row-level security policies driven by user attributes and groups, warehouse UDFs, inline tables, joins with automatic suggestions, the Data Explorer and your existing connections across Snowflake, BigQuery, Databricks, Redshift, PostgreSQL, ClickHouse, DuckDB and Athena all carry over unchanged.

What is different is that all of it is now versioned, comparable, and reachable by an assistant working under your permissions.

And it is not limited to dashboards. The same governed definitions power interactive analytics, Excel, embedded experiences, applications, assistants and agents. Define the business logic once. Use it everywhere.

What this changes, depending on where you sit

Data and analytics teams. More than one person can safely work on the model. Version history shows who changed what, and drafts let new contributors experiment without immediately affecting production. A second or third contributor stops being a risk and starts being capacity.

Heads of data. You have a clear answer when someone asks how AI is governed here. AI edits are attributed, validated and reviewable exactly like human edits. Who changed this measure, and was it a person? becomes a lookup rather than an investigation.

Analytics engineers. Find out from your model, not from your CFO. Missing fields, broken measures and incompatible data types appear where you can actually fix them, and schema drift stops being a fire drill.

Open it and change something

The new Semantic Layer Editor is available now in Astrato.

If you already use Astrato, the useful first step is small: open a semantic layer, name a version, and change the thing you have been putting off. That is the whole point — you can now find out what a change does before anyone else has to live with it. If you are evaluating Astrato, book a walkthrough and we will run it on your data.

The proof arrives the first time you restore something. You make the change, it turns out wrong, you compare, you roll it back, and nobody downstream ever knew. The model improved. Nothing broke.

That is what a semantic layer is supposed to feel like when the whole company — and everything the company builds with — is depending on it.