The semantic layer in Rig: bootstrap one from scratch, or import the one you already have

    A semantic layer is the shared definition of what your numbers mean: what counts as an active user, how revenue joins to customer, which rows to exclude. Rig is a fast way to build that layer for the first time, and an equally fast way to bring across a semantic layer you have already invested in elsewhere.

    What a semantic layer is, and why it matters

    Raw warehouse tables do not answer business questions on their own. The same word, "revenue", can mean five different things depending on which table you query and which filters you apply. A semantic layer fixes that by holding the canonical definitions in one place: every metric, the SQL behind it, the joins it relies on, and the rules that govern it.

    Once those definitions live in Rig, every answer is consistent, whether it comes from an analyst, a business user asking in plain English, or an AI tool like Claude or Cursor plugged in over MCP. The metrics view is where the whole library lives, and where you certify the definitions your team can trust.

    Your top ten percent of metrics, the revenue and churn definitions everyone leans on, belong in the semantic layer. But Rig also builds the wider context graph around them: the tables, joins, and business terms that help you draft those metrics in the first place and support all the data work that does not fit neatly into a single metric. When you are chasing a transaction or logistics log for one order ID, there is no semantic metric for that, and the surrounding context is what lets Rig answer anyway.

    Bootstrap a semantic layer from scratch

    If you have never had a semantic layer, this is the most common place to start. Rig reads your connected warehouse, understands the shape of your tables, and helps you turn the definitions in your team's head into certified metrics. You do not need a modelling project or a migration plan, you start defining metrics on day one.

    Every metric carries its full definition with it. Open one to read its description, see the exact SQL behind it, and run it inline, so anyone can check what is certified and reuse it instead of rewriting the same logic.

    The metric generator does the first draft for you

    Inside the Rig app, click create a metric, type a name like ARR, and describe it in plain English. You do not need to remember the exact field names or write the SQL yourself. Hit Magic Hydrate and Rig's agent goes out, finds the relevant data context, and drafts the metric for you, for example sum of value from your Attio deals.

    Every draft is checked against the Rig sandbox, which holds synthesized, PII-safe equivalents of your data, so you can confirm the SQL actually returns results before anything is certified. Review the generated query, run it inline to eyeball the rows, then save it as a draft or save and certify when you are confident.

    💡 Pro tip
    Use @table_name or @column_name hints in your description to point the generator at the right source data, for example "Count of distinct users who logged in at least once in the past 30 days, from @analytics.fct_logins using @user_id".

    Or work headless from Claude

    The second way is to do exactly the same thing without leaving Claude. Because Rig connects over MCP, you can ask a question like "how do we calculate revenue?" and the agent searches your metrics, sees there is no revenue metric yet, and drafts one, returning the SQL and the measure before anything is saved.

    The wider context graph pays off here too. If you notice two columns that look similar, say value and value_v2, you can ask the difference and Rig digs into the underlying data: it finds the test transactions inflating one of them, then updates the canonical SQL to exclude that DLT load. You go from a rough definition to a clean, governed metric in the same conversation, and it lands in the same library your team and every AI tool query.

    Already have a semantic layer? Import it

    You do not have to rebuild what you already have. If your definitions live in LookML or another semantic layer, Rig can import and migrate them, mapping each existing metric to a Rig metric with its SQL, joins, and description intact. Teams that have spent years curating LookML can move that work across in minutes rather than rewriting it by hand.

    Importing also gives you a clean upgrade path. Bring your definitions in as they are, then let Rig serve them to every AI tool and business user over MCP, with the same certification and governance you would get from building from scratch.

    Was this guide helpful?