A semantic model describes data in business terms: the measures (revenue, order count), the dimensions they can be sliced by (month, region), how tables join, and the rules behind each number. BI tools read it so everyone uses the same definitions.
For example, a semantic model for retail sales might define a measure Revenue as the sum of order line amounts excluding returns and tax, a measure Orders as the count of distinct order ids, and Average basket as revenue divided by orders. It lists the dimensions these can be sliced by, such as date, store, region and product category, and the joins that connect them. A dashboard that asks for revenue by region by month then gets the same numbers as a spreadsheet that asks the same question.
Ratios are where definitions matter most. Average basket by region must be computed as each region's revenue divided by its orders, not as an average of each store's average basket, which weights small stores the same as large ones. A semantic model encodes that once, so every tool computes it the same way. BI products such as Power BI have their own semantic model formats, and some data platforms offer metric definitions in their catalogs.
A semantic model sits on top of gold tables at a known grain: the model defines meaning, and the tables hold the data. See also fact table, lineage and the sample dashboard, whose charts come from synthetic sales data.
A semantic model is also the natural place to write down which dimensions a measure may be sliced by: a balance can be summed by account but not by day, and the model can say so, so a tool does not offer a total that means nothing. See also grain.
When you ask Emolysis a business question, the agent proposes a semantic model first, for you to confirm, and then builds the gold table that answers the question. See Dashboards from a question and grain. Wrong dashboard numbers often come from a wrong definition, so reading the model before the table is built is the cheapest check.