Semantic layer

The layer between an analytical engine and whatever is asking it questions: a place where business meaning — what revenue is, which rows a given user may see, how monthly is computed — is defined once, so that callers ask for a metric instead of writing the join. It compiles those definitions into SQL that an engine like clickhouse, duckdb or snowflake actually executes; it stores no data of its own.

The spoke's founding sources were about where data lives and how it is scanned. This is the first concept here about how it is asked for, entered with slayer (2026-08-31) — the read-side counterpart to jitsu, which brought the write side of the same "above the engine" layer. One source deep, and this page says only what that source and its own framing establish.

What it is for

Two jobs, usually bundled:

• Consistency. One definition of a metric, reused by every dashboard and query, so two teams reporting revenue report the same number. This is the reason the layer exists in the BI stack.
• Governance. Row-level security, read-only access, and a restricted surface, applied at the layer rather than in each consumer.

The established names in the category — dbt (metrics defined alongside transformations), Cube, and the Open Semantic Interchange (OSI) config format — are known here only as things slayer imports from. None is paged; that is a gap, not a judgment.

The argument that agents change the requirements

slayer makes a specific claim about why the BI-era design does not transfer, and it is the reason this page exists rather than a line on analytical-databases:

Classical semantic layers bind a metric to its aggregation at definition time. Monthly revenue is a defined object; a dashboard user picks from the defined objects, so the boundary of what was predefined is invisible to them. An agent answering an open question crosses that boundary on the first ratio, the first year-over-year comparison, the first request for an average where a sum was defined.

The proposed alternative moves aggregation to query time while keeping definitions and governance at design time — a column revenue defined once, composed on demand as revenue:sum, revenue:avg, revenue:sum / *:count, or time_shift(revenue:sum, -1, 'year').

What this trades is worth naming. A predefined metric is a guarantee that everyone gets the same number. An expression grammar hands composition back to the caller — and the caller in the motivating case is a language model. The constraint that remains is real (the model composes governed columns in a fixed grammar, not free SQL), but consistency stops being structural and becomes a property of how each caller composes. Nobody in this corpus has measured which way that comes out.

The position against text-to-SQL

A semantic layer for agents is implicitly an argument that letting a model write SQL against a raw schema is the wrong interface — too much surface, no governance, no shared definitions. The competing view is that models are now good enough at SQL that a layer is overhead. This wiki holds no evidence either way. slayer offers one illustrative screenshot and no benchmark; that is the entire evidence base for the claim, and it is a growth edge rather than a finding.

Related

slayer · analytical-databases · motleyai · clickhouse · duckdb · snowflake · tinybird · synthesis