Operating rules
Write plain-language rules that tell Ace how your team wants incidents diagnosed and fixed, and understand exactly where Ace applies them and what they can't do.
Operating rules are short instructions your admins write once, such as "Prefer a rollback over a forward fix during business hours." Ace follows them when it diagnoses an incident and when it recommends, prepares or explains a fix. Coding agents read them through the Ace MCP server.
Rules guide Ace's reasoning and never add authority. Your action policy controls what Ace may change and who approves it, and the policy doesn't read operating rules.
Write a rule
- In Ace, open Settings > Actions > Operating rules.
- Select Add rule.
- Write the rule in the text box.
- Open Applies to under the rule and choose the kinds of work it covers. A new rule applies to Everything until you change it.
- Select Save rules.
To remove a rule, select × next to it, then Save rules. Saved rules apply from the next investigation or proposal.
Only admins can add, change or remove rules, because they shape every investigation in the workspace. Members see the list read-only, with the note "Only admins can change operating rules."
Where a rule applies
| Applies to | Covers |
|---|---|
| Everything | All of Ace's reasoning. A rule for Everything always applies. |
| Diagnosis | How Ace diagnoses an incident. |
| Recommendations | The fixes Ace recommends. |
| Pull requests | Changes Ace makes to your repositories. |
| Live operations | Operations on running systems, such as scaling, restarting or failing over. |
A rule can cover several kinds of work and applies whenever any of them matches.
Limits
| Limit | Value |
|---|---|
| Rules per workspace | 20. Add rule disappears at 20. |
| Length of a rule | 400 characters. A counter appears as you near the limit. |
| Line breaks | None. Line breaks become spaces when you save. |
| Kinds of work | At least one per rule. |
| Scope | Your whole organization. There are no per-workload or per-environment rules. |
Examples
| Rule | Applies to |
|---|---|
| Prefer a rollback over a forward fix during business hours. | Recommendations |
| For the payments service, treat any change to the ledger tables as a data issue first and check recent migrations before suggesting code changes. | Diagnosis |
| Keep fix pull requests to one service and include a test that reproduces the failure. | Pull requests |
| Never recommend restarting the orders database during the EU trading day (08:00–17:00 CET). Scale read replicas instead. | Recommendations, Live operations |
| Don't scale checkout below 4 tasks. | Live operations |
| Our Sentry alerts on the batch importer are noisy at night. Weigh them against the job's own failure metrics before calling a cause. | Diagnosis |
Good rules say what to prefer or avoid. Rules apply to the whole organization, so name the service in the text when a rule is about only one.
How Ace uses your rules
| Where | Rules it uses | What they do |
|---|---|---|
| Investigations | Diagnosis, Recommendations, Pull requests, Live operations and Everything | Shape the root cause analysis and the recommended steps. |
| Operations on running systems, including Kubernetes | Recommendations, Live operations and Everything | Shape which operations Ace proposes and how. Approvers see the relevant rules on the plan. |
| Fix pull requests | Pull requests and Everything | Narrow the change. They never widen the approved repository or what the pull request is for. |
| The Ace MCP server | All, or the kind of work the client asks for | Returned by get_operating_rules. |
What rules can't do
Rules can narrow what Ace recommends, set an order of preference or add conditions, but Ace ignores any part of a rule that asks for more authority. A rule can't:
- grant a permission, or let someone approve an action they otherwise couldn't
- approve or run an action
- widen the repositories, resources or operations an action may touch
- turn on Automatic for an action, or lower the track record it needs
- change how confident Ace has to be before it acts
Your action policy and approval rules control those. A rule saying "always roll back checkout automatically" has no effect on whether a rollback runs automatically.
Rules are guidance, so a recommendation can still miss one. Put anything that must never happen without a person in your action policy instead, by setting the action to Off or Approval, adding a change freeze or requiring two approvers, and review proposals as usual before you approve them.
Reading rules from your coding agent
MCP clients read the same rules with get_operating_rules. To filter by kind of work, pass applies_to as all, diagnosis, remediation, code_change or live_operation, and rules for Everything are always included.
{ "applies_to": "code_change" }The result lists each rule with the kinds of work it covers, under the note "These narrow what Ace recommends. They never grant permissions or approve anything."
Before you open a pull request for INS-1018-ab12, call get_operating_rules with
applies_to "code_change" and follow every rule it returns.Operating rules and memory
Operating rules are what your admins tell Ace, and memory is what Ace learns from your incidents. Neither can expand what Ace may do. For a side-by-side comparison, see Memory and operating rules.
Next steps
Actions and approvals
Every change Ace can make, how your action policy decides what needs a person, who can approve, how undo works, how Ace verifies recovery, and how earned autonomy lets an action run automatically.
Integrations
Every tool Ace connects to, what Ace reads and can change in each, which ones open incidents, and how connecting a tool works.