Consider a hypothetical team that asks an agent to flag accounts at risk of churning this quarter. The semantic layer defines active customer as any account with a paid order in the last 90 days, and the agent applies that definition exactly. This team, though, works from renewals: the agent should judge each account against its own contract renewal date and use the company’s fiscal calendar to define the quarter. The resulting list still includes one-time purchasers with no contract to renew and does not distinguish accounts by renewal date.
The shared definition was correct, but the team had not specified how to apply it to this renewal task. A semantic layer answers what the data means across the company. An AI task adds task-specific requirements: which records count, for which period, with which exceptions, and whether results on the data meet the task’s criteria.
Key takeaways
- Between September 30 and October 5, Snowflake, DataHub, and Databricks each announced or described work on governed business meaning: semantic views, governed metrics, and an ontology of authoritative tables and rules.
- A shared definition answers what a metric means across the company. A specific task often needs a task-specific subset or definition, a different time window, or written-down exceptions.
- CUBIG recommends writing down the task’s own conditions and checking them against the shared definitions before an agent acts on governed metrics.
- Then compare results on the original data and the task-prepared data under the same model, prompt, and evaluation criteria, and keep each result linked to the data version used for that run.
What changed: semantic layers for AI agents
Within a week, three data platforms announced or described work on shared business meaning. On September 30, 2026, Snowflake made Semantic Studio, its authoring environment for semantic views, generally available. On October 1, DataHub described its Metrics Catalog, which makes business metrics governed entities instead of definitions scattered across tools, with the stated goal of keeping an agent from inventing its own business logic at query time. On October 5, Databricks described how Genie Ontology captures which tables are authoritative, which business rules apply, and who the trusted experts are. In its view, the problem is missing enterprise context rather than model intelligence.
A semantic layer maps tables and columns to business terms such as revenue or active customer, so people and tools calculate them the same way. An agent that queries governed definitions is less likely to compute revenue its own way, and an ontology that marks authoritative tables helps it avoid a stale copy. Both address real causes of wrong answers from agents. They do not settle how a given task should apply those definitions.
What the renewal example shows
The semantic layer gave the correct company-wide answer. The team had not written down which accounts the renewal task covers or which accounts have renewal dates within the fiscal quarter, and nothing checked the list against the task’s purpose. Where a team stores those conditions matters less than whether it states them and tests the result. We made the same point when we wrote that AI data preparation starts with the task. It also builds on our piece on why agent-ready data needs semantic context: agents need shared context first, and each task adds conditions on top of it.
What a semantic layer covers, and what each AI task adds
The table below reflects how CUBIG splits this work in practice. Depending on the platform and how a team configures its semantic layer, parts of the right-hand column may sit in the semantic layer as well.
| Question | Usually answered by a semantic layer | Usually added for each AI task |
|---|---|---|
| What does this metric mean? | A company-wide definition, such as active customer | Whether the task needs a task-specific subset or definition, such as accounts with a contract up for renewal |
| Which source is authoritative? | The certified table or view for each business concept | Which records within it count for this task, and which to leave out |
| Over what period? | Standard calendars and default windows | The window and calendar this decision uses, such as a fiscal quarter |
| Which exceptions apply? | Rules that hold across the company | Exceptions owned by one team or one process |
| Is the data good enough for this task? | Outside its typical scope | A comparison of original and task-prepared data under fixed model and evaluation conditions, kept with the data version |
How to prepare data for an AI task on top of a semantic layer
- Write down the task’s own conditions. Which records count, the time window, the exceptions, and the decision the output feeds.
- Map each condition to the shared definitions. Mark where the governed metric fits as is, where the task needs a task-specific subset or definition, and where no definition exists yet.
- Record the task-specific rules. Keep them where the team can find them, whether in the semantic layer or alongside the task, without changing the company-wide definition other teams use.
- Test the task under fixed conditions. Hold the model, prompt, and evaluation criteria constant. Compare results on the original data and the task-prepared data using a labeled sample with expected outcomes. Assess both results against the task’s acceptance criteria; improvement alone does not establish that the prepared data meets them.
- Keep the result with the data version. When the shared definitions or the data change, rerun the test before relying on the earlier result.
Steps 1 to 3 need people who know the work. For context engineering at the agent level, see our guide to context engineering for AI agents.
Related product: Syntitan
For structured data, CUBIG’s Syntitan supports the task side of this work. Teams define a use case, prepare data for it, validate the data with a selected model or agent under fixed evaluation conditions, and release it as a data version with a validation result of Qualified, Not Qualified, or Inconclusive for that task. The team defines the business rules and acceptance criteria; Syntitan supports data preparation and validation for the defined use case. Explore Syntitan, or read more about what AI-ready data means.
