All guides
    Step 3 of 5·Rig basics

    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 certified metrics.

    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.

    Certified 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:

    • Is there a different table people should be using instead for certain questions?
    • Are there column values, units, or formats in this table that are easy to misinterpret?
    • Are there rows that should be excluded from most queries?

    Metrics

    💡 Draft vs Certified metrics
    New metrics start as drafts. A draft metric is visible but not injected into SQL generation. Once you test and promote it to Certified, it becomes the canonical definition, every time someone asks a question that matches this metric, Rig uses your exact formula.

    1. Navigate: Metrics > New Metric.
    2. Choose between Natural Language and SQL (for when you have the exact canonical query).
    3. Fill in the metric details:
      • Name: a clear, human-readable label (e.g. "Monthly Active Users", "Gross Revenue").
      • Description: explain what the metric measures and any important caveats.
      • Category (optional): helps organise metrics (e.g. "revenue", "engagement", "operational").
    1. Click Magic Hydrate to auto-generate SQL. This will create a draft metric.
    2. Click Save as draft if you're not 100% sure it's right, or Save and certify if confident.
    3. Before certifying, test the metric to make sure the generated SQL returns the numbers you expect. Review the SQL, query example, and validation results, and refine the description or SQL until it's accurate.

    💡 Pro tip for natural language mode
    Use @table_name or @column_name hints in your description to 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 @analytics.fct_logins using @user_id".

    Was this guide helpful?