Data models

Rig does not replace your modelling layer. Transformation logic stays in SQL and dbt, in your warehouse and your repository. Rig reads those models and adds a context layer on top: what each table and column means, how tables join, which metrics are certified, and the rules an analyst or agent should follow when querying them.

Warehouses

Rig can query BigQuery, Snowflake, Amazon Redshift, Databricks, Microsoft Fabric, PostgreSQL and MotherDuck (DuckDB). A MySQL database can be connected as a read-only source.

dbt

A dbt project's manifest.json gives Rig your models, their descriptions and their lineage. There are two ways to supply it.

Upload a manifest. Send the manifest produced by dbt build or dbt compile:

curl -X POST https://app.rig.so/jaffleshop/fde/context/upload-manifest \
  -H "Authorization: Bearer $RIG_SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d "$(jq -Rs '{content: .}' target/manifest.json)"

The body is a JSON object with one field, content, holding the manifest as a string. The manifest must contain nodes or sources and be at most 25 MB. The response is 201 with a run_id; Rig then rebuilds the join graph from the manifest in the background. The request is refused with 409 while another context build or a dbt Cloud pull is running; a refused upload stores nothing, so retry it once the run finishes. This operation is in Preview and requires permission to edit the context layer.

Connect dbt Cloud. With a dbt Cloud connection configured, Rig pulls the manifest from a completed job run. A dbt Cloud webhook pointed at POST /{client_id}/fde/context/dbt-cloud-webhook makes this happen after each successful run.

Context layer

Object	What it holds	Read through
Tables and columns	Descriptions, data types, sample values, usage	GET /{client_id}/fde/context/tables, MCP search_tables, get_table_columns
Joins	Known join paths between tables	GET /{client_id}/fde/context/joins, MCP find_join
Metrics	Named, SQL-defined measures with a status	GET /{client_id}/metrics/list, MCP search_metrics
Business terms	Vocabulary and its definitions	GET /{client_id}/fde/context/terms, MCP get_business_context
Usage rules	Guidance such as required filters and tables to avoid	GET /{client_id}/fde/context/rules, MCP get_usage_rules
Areas	Sub-domains that group tables, metrics, rules and documents	MCP get_area

The HTTP operations are in Preview; see the API reference.

Metrics

A metric has a readable name, a description, a category and, where it is defined precisely, the SQL that computes it. Each metric has a status. Certified marks the definitions that agents are told to reuse instead of deriving their own.

Metrics can be created and edited in the application, through the metrics operations (Preview), or by an agent through the MCP tool manage_metric. Edits are subject to the role's permissions: a role that may only propose changes has its edit queued for approval. Changes are recorded in an audit log.

Metric definitions can also be imported:

• from an OSI (Open Semantic Interchange) document, with POST /{client_id}/metrics/osi. The import is a dry run unless dry_run=false is passed.
• from Lightdash metric definitions in dbt YAML, with POST /{client_id}/metrics/import/lightdash (Preview).

What Rig writes to your warehouse

SQL submitted through the API and through the MCP tool execute_sql is read-only. Rig loads data into a warehouse only when that warehouse is the destination of ingestion. The one other route is the MCP tool call_procedure, which runs a stored procedure, and only one that the workspace has explicitly allow-listed.