Introducing the New Astrato Semantic Layer Editor

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 in a deck.

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

Now you are in a meeting where two people are quoting the same metric and disagreeing by four percent, and the conversation stops being about the business and starts being about whose number is correct.

Nobody did anything wrong. The problem is that both answers were built from scratch, from whatever the assistant could work out on its own. It is the spreadsheet problem all over again — the same question producing different answers depending on who asked it — except now it happens in seconds rather than weeks.

The instinct is to slow this 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 giving it up because governance asked them to.

So rather than fight it, we gave it something solid to build on.

The new Astrato 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. 

Nash inside Astrato, or Claude, ChatGPT and Codex connected from outside. Same definitions. Same permissions. Same answer, whoever asks.

It is available to every Astrato customer today.

‍

New: Versioning - change the model without holding your breath

Here is the 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 logic you spent months centralising quietly crept back into individual dashboards.

The editor now keeps a full history of your semantic layer: what changed, when, and who changed it.

Open Versions, put any earlier version side by side with what you have now, and see every difference sorted into tables, fields, joins, dimensions and measures.

Then take back all of it — or tick the single definition that went wrong and restore only that.

Nothing is destroyed on the way. A restore lands as a new version on top of your history, so the trail stays intact and you can undo the undo.

What that changes is not really a feature. It is a mood. When a bad edit costs you four minutes instead of a week of apologies, you start making the changes you have been avoiding — and more than one person can safely own the model, because history shows exactly who did what.

New: Error handling - Find out issue 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.

Two things now stop it.

The first is that a broken model cannot be published. Beside Publish sits an issues count, and while anything is unresolved, publishing is blocked and the button tells you exactly what is holding it up. 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.

The second is that Astrato watches your warehouse for changes underneath you. It checks the tables, columns and functions your model actually uses. A changed column type lands in a new draft rather than going live on its own. A missing table blocks publishing until you repair it. And when Astrato cannot tell whether something was removed or your credentials just cannot see it, it says so rather than guessing, because a model that is almost right is worse than one that is honestly uncertain.

Repairing is a redirect, not a rebuild. Point the broken table or field at its new source, and your semantic names and every reference to them stay intact. A rename upstream no longer means a rebuild downstream.

New: MCP integration - bring your own AI, keep your own governance.

Connect Claude, ChatGPT, Codex, or another AI assistant to Astrato and let it read your semantic layer, search it, and build measures for you — on your behalf, with your permissions, on your organisation's data.

You are not handing over a password. You sign in to Astrato yourself, and the assistant gets a limited pass tied to your account that lists exactly what it may do. You can withdraw it whenever you like.

And every edit an assistant makes is a tracked edit. It lands in your working copy, appears in version history beside your own changes, and still has to clear validation before it can be published. An assistant cannot do anything you could not do yourself — and it cannot do it invisibly.

If you would rather not bring one at all, Nash is already inside the editor. Describe the change you want in plain language, steer it while it works, and it goes through exactly the same governed operations as anything else.

This is the part worth sitting with. 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. Your team stops being the bottleneck without becoming the risk.

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 the point.