Rule sets
A rule set groups rules so one call checks an output against all of them. The rules are judged in parallel and the call costs the same as checking one rule. Each rule in a set is pinned to a version, so a set behaves the same until you change it.
What a rule set is
- A name, a description, tags, and a list of pins. A pin is a rule and one version of it.
- Rule sets reference rules. They never copy them, and they can include public rules.
- A rule set is versioned like a rule. Every change to its pins saves a new rule set version, and earlier versions stay readable and can still be run by version ID.
- A rule set belongs to your company and takes its catalog’s visibility. It has the same statuses as a rule.
Build one
Ask your agent, or use Rule sets in the portal. The agent finds the rules with list_rules, shows you which rules and versions it plans to pin, and saves the set with create_ruleset once you agree.
| Field | What it is |
|---|---|
name | The rule set's name. |
description | What it is for. |
tags | For finding and grouping. |
pins | A list of rules, each as a rule_id with an optional version_id. A pin with no version uses the rule's active version, and the result says which version it used. |
The new rule set is saved as a draft. Vindex refuses a set that has no rules, holds a rule twice, pins a rule you cannot see or a version that does not exist, pins a public rule at a version that is not active, pins a disabled or archived rule, or is over the size limit. Each refusal names the rules at fault. You can pin your own rules in draft or test so you can test the set with them, but a set cannot become active while it pins a draft rule.
In the portal, selecting rules by tag saves a fixed list of pins. Rules you tag later are not added to the set.
Run one
Call validate with a ruleset_id instead of a rule_id. Without a version_id, the active version of the set runs.
- Every pinned rule is judged in parallel, and the call returns within the MCP server’s 70-second limit.
- The set passes only if every rule passes.
- The result carries one pass or fail for the set, the rules that failed, and every rule that was judged with its own result. See critique results.
- The call is charged once, $0.03, whatever the number of rules.
- If any rule gets no answer after retries, the whole call fails, the hold is released, and nothing is charged. You never get a partial result.
For a company that only allows approved items, a rule set version has to be on the approved list before an agent can run it.
Move a set to a new rule version
A new active version of a rule does not change any rule set that pins the old one. list_rulesets and the portal show, for each pin, whether a newer active version exists.
- Re-pin the rule with
update_ruleset, or use Update to latest in the portal. The result is the next rule set version, in draft. - Test it on outputs you know the answer to.
- Set it to active. Agents that send no version now get it. Agents that name an earlier version still get that one.
update_ruleset without pins changes status, metadata, or the active version without saving a new version.
Archive a set
Set the status to archived with update_ruleset, and name a replacement with replaced_by if you want agents pointed at it. Before you confirm, you see how many runs it had in the last 30 days. A critique against an archived set is refused with RULESET_ARCHIVEDand the replacement’s ID, and nothing is charged. Archived sets and their versions stay readable by your company and can be restored.
Reading a rule set
list_rulesetsreturns active rule sets from your own catalog, your approved list, and the public catalog. Reading one returns its pins with each rule’s name, description, owner, and version. Rule content is read with list_rules.
See also rule format and the MCP tools.
