Why a semantic layer

Your warehouse is now modeled, loaded, gated, and resolved — and Harbor Lane can still have the bad meeting. Finance queries SUM(qty * unit_price) WHERE status = 'completed'. Marketing forgets the status filter. The intern includes refunds. Three dashboards say 'Revenue'; three numbers appear; trust in the entire data platform — the thing you just built — evaporates over a definition dispute no table can settle.

The missing layer is semantic: a place where business concepts — net revenue, active customer, refund rate — are defined once, in a machine-readable form, and every consumer (dashboard, notebook, AI agent) computes them from the shared definition instead of re-deriving them ad hoc. Tables answer 'what data exists?' The semantic layer answers 'what do our words mean?'

What lives in it

• Metrics — a name, an owner, a plain-language description, and the exact computation: measure expression, base table, mandatory filters. net_revenue = SUM(qty * unit_price) FROM fct_order_lines WHERE status = 'completed'.
• Dimensions — the approved ways to slice: by order_date, channel, category. Declaring them prevents the subtle crime of grouping a metric by a column at the wrong grain.
• Grain & join rules — which joins are legal, so 'revenue by category' always routes through dim_product the same way.

Why AI turned this from nice-to-have into load-bearing

For a decade, semantic layers were a BI-team luxury. LLMs changed the stakes. When you ask an analytics agent 'what was net revenue by channel last week?', the agent either (a) improvises SQL from raw schema — plausible, fluent, and wrong in exactly the ways interns are wrong — or (b) calls a metrics layer, which compiles the governed definition into SQL deterministically. Option (b) is the difference between an AI that sounds right and an AI that is right. The Conversational Analytics Agent course builds an agent on pattern (b); this module builds the layer it calls.