---
title: "Teach Rig your tribal knowledge — Rig guide"
description: "Use usage rules and certified metrics to encode your team's definitions, edge cases, and rules so Rig answers questions your team's way."
canonical: "https://rig.so/guides/tribal-knowledge"
format: markdown
---

Search guides, references, playbooks…⌘K

Browse guides

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

- 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").

![Create New Metric dialog in Rig with Natural Language and With SQL tabs, fields for Metric Name, Description, Category, and a Magic Hydrate button.](https://rig.so/create-new-metric.png)Click to view full size

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?

Yes No

Step 9 of 10

---

- [This page as HTML](https://rig.so/guides/tribal-knowledge)
- [Site map for language models](https://rig.so/llms.txt)
- [API and agent documentation](https://rig.so/developers)