Teach Rig your tribal knowledge

    The numbers in your warehouse only become reliable answers once Rig knows your team's definitions, edge cases, and rules. There are two features for this: usage rules and governed metrics.

    Watch: Governed metrics, end-to-end

    When should I use each?

    Usage rules

    • Use to add caveats to how you and your team use the data, or when your query misunderstands the table grain or picks the wrong table.
    • If a metric's source table has known caveats (special revenue recognition rules, date edge cases, etc.), add those as usage rules on the table.

    Metrics

    • Use when there should be one agreed-upon way to calculate a KPI like revenue, churn, or conversion rate, so that every query gets the same number.

    Usage rules

    What's the purpose of adding a usage rule?

    • A usage rule tells Rig something about a table that isn't obvious from the schema, historical queries, and other data sources Rig ingests on its own.
    • When Rig generates SQL, it reads all the rules attached to the tables it's using and adjusts accordingly.
    • Without rules, Rig will miss any 'gotchas' or tribal knowledge that your team has built up.

    What do you need to know before drafting a usage rule?

    You'll need to know what information someone needs to use the table right, e.g. caveats:

    • A different table people should use instead for certain questions.
    • Column values, units or formats in this table that are easy to misread.
    • Rows that most queries should exclude.

    Metrics

    💡 Uncertified vs certified metrics
    A new metric is not certified yet. Its status reads NL Only while it is a definition without SQL, and Draft SQL once it has SQL. When you are sure it is right, open it and click Mark as certified. A certified metric is the canonical definition, so whenever someone asks a question that matches it, Rig uses your exact formula.

    1. Navigate: Metrics > New Metric. The dialog is headed Create New Metric.
    2. Choose between Natural Language and With SQL (for when you already have the exact canonical query).
    3. Fill in the metric details:
      • Metric Name: a clear, human-readable label (e.g. "Monthly Active Users", "Gross Revenue").
      • Description: explain what the metric measures and any important caveats. On the Natural Language tab, type @ to search for a table or column and mention it.
      • Category (optional): helps organise metrics (e.g. "revenue", "engagement", "operational").
    1. On the Natural Language tab, click Build in Chat. A chat opens where the agent finds the right tables, writes the SQL and tests it with you, then saves the metric once you confirm the result. If you only want to record the definition for now, click Save as NL-only and add the SQL later. On the With SQL tab, paste the query and click Create Metric. On the viewer role, each of these sends the new metric to an owner or editor for review first. After Save as NL-only or Create Metric, Rig says Submitted for review; after Build in Chat, the chat tells you it was sent for review.
    2. Check the numbers before you certify. There is no test button in the dialog: compare what the chat returns with a figure you already trust, such as your BI tool or the finance team's report, and refine the description or SQL until they agree. Then open the metric and click Mark as certified. Owners and editors certify directly; for analysts and viewers it goes for approval first.

    💡 Pro tip for natural language mode
    Type @ in your description to pick a table or a column, and Rig inserts the name you picked, such as @fct_logins for a table or @user_id for a column. Hints like these help Rig find the right source data, for example: "Count of distinct users who logged in at least once in the past 30 days, from @fct_logins using @user_id".

    Was this guide helpful?