Chat
Ask questions that reuse approved SQL.
Semantic layer
Build a semantic layer from reusable SQL definitions for your most important metrics and models. Basedash AI can reference them across chat, charts, dashboards, insights, and automations.
14-day trial. No credit card required.
Data / Production warehouse
Run definition
Definitions
Activation rate
activation_rate
Monthly recurring revenue
mrr
Qualified pipeline
qualified_pipeline
Cohort retention
cohort_retention
Activation rate
Users who complete onboarding within seven days of signup.
01 select date_trunc('week', signed_up_at) as week,
02 count(*) filter (where onboarded_at <= signed_up_at + interval '7 days')
03 / nullif(count(*), 0) as activation_rate
04 from users where email not like '%@basedash.com'
reference
activation_rate
latest week
42.8%
used by AI
Everywhere
Definition
One vocabulary for your data, shared by people and AI.
A semantic layer is a centralized set of metric and business-logic definitions that sits between your data and everyone who queries it. Instead of every dashboard, report, and AI prompt redefining what counts as revenue, an active user, or churn, the definition is written once and reused everywhere — so every answer resolves to the same number.
This matters even more with AI in the loop. When a model generates SQL against raw tables, it has no way to know your business rules and will improvise them. Basedash constrains its AI to governed definitions, so answers in chat, dashboards, insights, and automations stay consistent instead of drifting query by query. Unlike standalone layers such as dbt Semantic Layer or Cube, it is built into the BI tool itself — plain SQL, no separate modeling infrastructure to deploy.
Why it matters
Save the exact SQL once. Reference it everywhere with a single line.
01Define once
02Reference anywhere
Monthly recurring revenue
v12select date_trunc('month', period) as month,
sum(amount) filter (where recurring)
as mrr
from invoice_lines
where not is_trial and not is_credit
Admin-ownedmrr
Net revenue dashboardRan 2m ago
with mrr as (
{{ definition("mrr") }}
)
select * from mrr
$59K+24%($48K)
Coverage
The semantic layer follows the work your team already does in Basedash.
Charts
Generate visualizations from trusted models.
Dashboards
Keep every report on the same calculation.
Insights
Spot trends from consistent metric logic.
Automations
Schedule reports with deterministic SQL.
SQL editor
Compose definitions inside larger queries.
Examples
Start with calculations that show up in dashboards, board reports, and chat.
Definitions
3
Monthly recurring revenue
RevenueRecurring invoice lines, excluding trials and one-time credits.
{{ definition("mrr") }}2d ago
Activation rate
GrowthUsers who complete onboarding within seven days of signup.
{{ definition("activation_rate") }}5d ago
Cohort retention
ProductWeekly retained accounts by signup cohort and plan.
{{ definition("cohort_retention") }}1w ago
Governance
Looker-grade metric governance, owned in plain SQL instead of LookML.
The semantic layer is more than reusable SQL snippets. It is where enterprise teams centralize the metrics the business depends on, control who can change them, and keep an auditable record of every change — the same governance backbone that Looker provides through LookML.
| Governance capability | Looker LookML | Basedash definitions |
|---|---|---|
| Single source of truth | Metrics modeled once in LookML and reused across Explores. | Metrics defined once as SQL and reused across every surface. |
| Centralized ownership | The data team owns the model; changes ship through code review. | Admins own definitions; members can run them but not edit them. |
| Change history and audit | Versioned in Git alongside the rest of the project. | Every edit creates a restorable version with full history. |
| Documented business meaning | Descriptions and labels live inside the model files. | Each definition carries a name, reference, and description. |
| Consistent AI and query logic | Explores constrain how analysts query modeled fields. | AI reuses approved definitions instead of inventing SQL. |
| Reuse surface | Explores, Looks, and dashboards. | Chat, charts, dashboards, insights, automations, and the SQL editor. |
| Access scope | Access grants and access filters scope modeled fields. | Definitions are scoped per data source under workspace roles. |
| Implementation cost | Requires learning and maintaining the LookML modeling language. | Plain SQL — no new modeling language to staff or maintain. |
Migrating from Looker? See how governance continuity maps to a modern BI tool, or read the Looker migration playbook.
Semantic layer, answered.
What is the Basedash semantic layer?
The Basedash semantic layer is powered by definitions: saved SQL queries scoped to a data source. Each definition has a name, reference name, description, and SQL query that Basedash can expand inside other queries.
How does a semantic layer keep metric definitions consistent across teams?
Every chart, dashboard, chat answer, insight, and automation that references a definition resolves to the same governed SQL, so two teams asking the same question get the same number. Admins own the definitions, members can run but not edit them, and every change is versioned — which removes the classic BI failure mode of five dashboards reporting five different revenue figures.
Should we use a built-in semantic layer or model everything in the warehouse?
Warehouse modeling (views or dbt models) works well for heavy transformations, but metric logic defined only in the warehouse is invisible to the BI tool's AI and requires an engineering deploy for every change. A built-in semantic layer keeps metric definitions next to where they are consumed, so the AI can reference them directly and admins can update them without a pipeline release. Many teams use both: dbt for transformation, Basedash definitions for the governed metrics on top.
How does the AI use the semantic layer?
Basedash gives AI agents a catalog of definitions for the data sources they are using. The AI can inspect a definition, reference it in SQL, or create and update definitions when an admin asks for reusable metric logic.
How do I reference a definition in SQL?
Use Liquid syntax like {{ definition("mrr") }} inside a query on the same data source. We recommend placing definitions inside CTEs so the final query stays readable.
How is the semantic layer different from skills?
They are deterministic SQL. Skills are prose instructions for the AI. Use definitions when the calculation itself should be reusable, and skills when the AI needs broader business guidance.
How does the Basedash semantic layer compare to Looker's LookML for governance?
It delivers the same metric governance teams expect from LookML — a single source of truth, centralized admin ownership, documented business meaning, version history, and AI that only reuses approved logic — without a separate modeling language. Definitions are plain SQL, so the data team governs metrics with the language they already use rather than maintaining LookML.
Can metric definitions be audited and version-controlled?
Yes. Every change to a definition's SQL or description creates a new version, and you can review the full history or restore a previous version from query history. Only organization admins can create, edit, delete, or restore definitions, so metric changes stay governed and auditable.