At almost every company trying to use AI with data, this meeting happens.
Someone asks the chatbot for last quarter's return rate. The dashboard on the wall shows a different number. Everyone turns to the data team.
Nobody did anything wrong. The dashboard uses definitions someone built years ago: what counts as a return, which stores are included, when the quarter starts. The chatbot never saw those definitions. It is guessing from column names. Of course the numbers differ.
The fix is not a smarter chatbot. It is giving both of them the same dictionary.
That dictionary is called a semantic model. It says, once and for everyone: net revenue means this. The fiscal quarter starts on this date. A store belongs to this region. When the dashboards and the AI read the same model, they give the same answer, and you can click any number to see where it came from.
The problem is that building one by hand is slow, so most companies never finish.
So Athena drafts it for you. Point it at your warehouse, say Snowflake or Databricks. It reads the tables, columns, relationships, and sample values. Then you describe the business in a few plain sentences, for example:
We sell parts to stores. Revenue is net of returns. A customer is a store, not a person.
From that, Athena writes a first draft: the ways you slice the data, the numbers you measure, and how the tables connect. Every definition shows the query behind it and the tables it came from. You read and edit it like a document.
Above the numbers, the nouns. Businesses talk in things, not tables: a brand, a plant, a legal matter, a deal. Athena can model those too, so one question can pull from a database and a set of documents at once.
Some older tables do not record how they connect to each other. When Athena cannot tell for sure, it flags the connection and asks a person instead of guessing.
People and AI should be looking at the same numbers. Now they can.
Catalog in. Measures out.
Three sentences draft the semantic model
Point Athena at Snowflake, Databricks, BigQuery, or the Athena Lakehouse. It reads the raw catalog: tables, columns, existing relationships, and sample values. Then you describe the business in a few plain sentences. We sell parts to stores. Revenue is net of returns. A customer is a store, not a person.
From that catalog and that paragraph, Athena writes a first draft of your semantic model. It proposes dimensions: Store, District, Region, Part, Category, Vehicle. It proposes measures: Net Revenue, Units, Fill Rate. It proposes how the tables connect. Every definition shows the query behind it, the tables it came from, and the reasoning for each choice.
You review it like a document. Accept, edit, or ask why. Version it. Then dashboards, agents, Athena Sheets, and notebooks query through the model with each user's own warehouse permissions. The semantic model comes first; the SQL comes second. The dashboard and the agent are now consistent because they read the same dictionary.
What you see on screen
On the left: a text pane where the data lead types the business context. On the right: the generated semantic model. Dimensions appear with their hierarchies. Store rolls up to District, District rolls up to Region. Part belongs to Category. Measures appear with their formulas. Net Sales excludes returns and adjustments. Each definition has a lineage arrow back to the catalog tables that feed it.
Controls sit beside each row. Accept takes the definition as written. Edit opens the formula and the reasoning. Ask why shows the sample values and column names Athena used to infer the relationship. If Athena cannot determine a join for certain, the row flashes amber with a flag: connection unclear. A person fills in the join key and approves.
Once you publish, the model is versioned. Every change has an author. Rollbacks are available. Dashboards, agents, sheets, and notebooks query through the model. Each query runs with the user's own warehouse permissions. The agent and the analyst see the same definitions, so they give the same answer.
Ontology above the semantic model
Businesses talk in things, not tables. A brand, a plant, a legal matter, a deal. Athena models those as typed objects in an ontology that sits above the semantic model. A Brand object can answer a SQL question about sales and a document question about marketing strategy. One question pulls from the database and the document set at once.
A CPG provider's product lines lived in different systems. As typed objects in one ontology, the same question works across both. A law firm's clients, matters, people, and documents become objects with governed actions. Conflicts checks and knowledge management queries run against the same graph. Object types carry actions with policies. An agent can propose mark PO as disputed; a human approves; the action is versioned and reversible.
Every object type exposes a versioned API. Applications and external systems consume the same definitions the dashboards do. The ontology bridges the document world and the SQL world.
Who it is for and what it replaces
Heads of data and analytics engineers. The team that keeps putting off the semantic model because building it by hand takes a quarter. Now it takes three sentences and a review session. If you already have a semantic layer in legacy BI or dbt, import it. Athena reads existing BI semantic model and can start from your dbt metrics. Then extend from there.
The semantic model replaces the dozen Measure files, wiki pages, and Slack threads where definitions live today. It replaces the meeting where someone asks which number is right, the dashboard or the agent. It replaces the guess the agent makes from column names when it has never seen your business logic. The model is yours. Export it. Data governance reviews; every change has an author; rollbacks are available.