What a Rule Contains
Each rule has two fields:
There are no rule types or categories — a rule is simply a named instruction. Write the content as a direct instruction, for example “Always exclude rows where
is_test = true” or “This metric only covers web traffic; note that in any answer that uses it.”
Which Items Can Have Rules
Rules can be attached to entities, metrics, dimensions, segments, and features. Skills do not carry rules — a skill describes a procedure, and its own clarifications and todos play that role. An item can have any number of rules. They’re listed in the Rules section on the item’s detail page.How the Agent Uses Rules
When the agent brings an item into a conversation — because a question needs it — it reads that item’s rules and treats them as mandatory instructions for the rest of the answer. Rules are never loaded globally; they only apply when their item is actually in use. Because rules travel with the item, they apply consistently no matter how the item is reached — whether someone asks about it directly or a metric pulls in a dimension for a breakdown.Managing Rules
Rules are managed from the Rules section on an item’s detail page in the Semantic Catalog. The section lists each rule by name and content, with controls to add, edit, and delete for users who can edit the catalog. How a change is saved depends on whether the item is versioned.Versioned items — entities, metrics, segments, and entity dimensions
For these items, rules are added and changed through the Builder chat, so the change goes through the same draft-and-release cycle as any other catalog edit. As with any Builder work, you first need to be editing the Context Layer — click Start Editing to take the lock if you don’t already hold it. See How the Builder Works for the lock and Context Layer Versioning for drafts and deploys. There are two ways to start:- From the item’s page — use the Add rule, Edit, or Delete control in the item’s Rules section. This opens the Builder chat with the request already filled in (for example, “add new rule to revenue metric”), so you just describe the rule.
- By typing in the Builder chat — ask for the change in your own words, naming the item and what the rule should do, for example “add a rule to the revenue metric: always exclude test users where
is_test = true” or “edit the Required Filters rule on the players entity.”
- Finds the item the rule belongs to. If your description matches more than one item, or none, it asks you to pick or clarify rather than guessing.
- Checks the rule fits — that the columns or concepts it names really exist on the item, and that it doesn’t contradict an existing rule or a memory. If something’s off, it tells you instead of creating the rule.
- Proposes the rule with a name and content for you to approve. Approve it and the rule is written into your draft; decline and the agent revises it — nothing is saved until you approve.
Live items — features and feature dimensions
Features, and dimensions that belong only to a feature, are not versioned — they’re managed live (see Features). Their rules are edited directly on the item page: Add Rule opens a short form with a Name and Content field, and the change is saved immediately, with no draft or deploy. Deleting a rule on a live item takes effect right away and can’t be undone.Editing rules requires permission to edit the Context Layer. Analysts and business users see an item’s rules read-only, so they can understand how the agent treats that data.
Rules vs Memory vs Skills
Rules overlap with Memory and Skills, so it helps to keep the distinction clear:
A quick test: if the instruction only makes sense when a particular item is in play, it’s a rule. If it holds no matter which item the agent uses, it belongs in Memory.