A rule (a guardrail in a rule set) is a limit, an exception or a person to ask, in the words of whoever stated it: its owner, or the policy’s own sentence. Every rule carries who to ask (the owner) and its source: the owner’s words with where they said them (a message, a review, a voice recording), or the file and section of a policy.

​
Taste and compliance

A rule is taste (how the team likes the work done: wording, design, conventions) or compliance (a requirement: money, approvals, access, data). A map drafted from a policy marks each rule. A taste rule nudges unless an editor picked another response for it; a compliance rule responds as the policy or its owner said. An editor can change either on the rules page; from then on the choice is explicit. A nudge’s suggested fix comes from the judge for a fuzzy rule. A precise rule can carry a fix template, set on the rules page, with {field} filled from the record: “Use the secondary variant instead of {button.variant}.” Without one, the nudge has no fix line. warn, the nudge’s old name, is still accepted in maps and on the API.

​
Precise and fuzzy rules

  • Precise: the rule has a predicate over the map’s facts, for example refund.amount > 500 or deal.discount_pct > 30. It runs the same way every time, in milliseconds.
  • Fuzzy: “equipment filed as a supply”, “a password in a ticket comment”, “salary data in a shared folder”. No predicate fits, so the judge reads the record on the server.
A precise rule whose fact the record doesn’t carry goes to the judge when the record names that field or carries free text, instead of being silently allowed.

​
Scope: what a rule governs

A map reaches every action of its kind. Without scope, a deploy-freeze rule would be judged on a branch creation, come back “can’t tell”, and ask a person for nothing. Scope says what each rule is about:
  • Claros drafts a scope for every rule when a map is published (one model call per map), and validates it against the map.
  • A rule with a known scope is judged only on calls that can be in it. An unknown scope (all four lists empty) is judged wherever its map applies.
  • Scope only gates the judge. A precise rule’s predicate always runs.

​
Edit a rule

On a map, open Rules. Editors and admins can reword a rule, change what happens when it’s broken, set who to ask, set its scope, or remove it. The same through the API:
Rewording keeps the source sentence and the predicate. Scope edits are strict: an unknown action, field or step is a 422. Members can read rules; editors and admins edit others’ rules.

​
Add a rule

Anyone in the workspace can type a rule on Home (Add a rule). It goes to the workspace’s Team rules map, owned by its author:
  • Live at once, or proposed. An editor’s rule, or anyone’s personal rule, is confirmed by definition: it takes the response they picked (stop, ask or nudge) from the next check. A member’s team rule runs in watch, marked Suggested, until an editor confirms it. Rules mined from your tools or proposed from answers also start in watch.
  • Every check considers Team rules when any of them apply, whatever the app, with no routing call. A workspace without Team rules pays nothing extra.
  • Applies to an app (a name like Slack, a host, or a Mac bundle id): only checks from that app. Blank: wherever the judge finds it relevant.
  • Just for me: only the author’s own checks and their agents’.
  • Edit or retire: the author or an editor or admin (POST / DELETE /api/rules/{id}). Retiring closes the rule’s version; its history stays. Each change is a rule version with source manual, confirmed by the author, in the signed log.