Modelling where you work
Modelling happens in one tool. The work happens in another.
Somebody opens a modelling tool, works out what a domain is called and what a metric counts, and writes it down. Everyone else goes back to the editor, the notebook and the query they actually work in, where none of it is visible.
So a definition is looked up once and remembered approximately after that. An engineer who needs to know what a table holds asks a colleague, reads the column names, or writes the version that looks right today.
What changes
Modelling stops being a separate job. Domains, models and definitions are drafted across your catalog rather than assembled by hand, and what comes back is a draft to review rather than a quarter of somebody's year.
What has been agreed is then reachable from the assistant already open in the editor, so an engineer asks what a table or a metric means where they are, rather than leaving to find out and settling for a guess.
What it rests on
Both, rather than one. An assistant with nothing agreed behind it answers from the raw schema like everything else, and agreed meaning nobody can reach from where they work is a document that stops being read.
- 01Agentic Modelling CopilotDomains, models and definitions drafted across your catalog, rather than assembled by hand.Modelling that consumes analyst quarters arrives as a draft to review.
- 02Semcore MCP ServerThe semantic core reachable from the assistant already in your editor, without leaving it to find out what a table or a metric means.Governed definitions are used in the tool engineers already live in, rather than consulted somewhere else.
An AI Readiness Review
A scoping conversation, and a look at your data estate as it stands: what your AI plans will need from it, where the gaps are, and which of them to close first. The findings are yours either way.