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

Source: https://tryace.dev/docs/concepts/operating-rules

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](https://tryace.dev/docs/mcp).

Rules guide Ace's reasoning and never add authority. Your [action policy](https://tryace.dev/docs/concepts/actions-and-approvals) controls what Ace may change and who approves it, and the policy doesn't read operating rules.

## Write a rule

1. In Ace, open **Settings** > **Actions** > **Operating rules**.
2. Select **Add rule**.
3. Write the rule in the text box.
4. Open **Applies to** under the rule and choose the kinds of work it covers. A new rule applies to **Everything** until you change it.
5. 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](https://tryace.dev/docs/concepts/actions-and-approvals) 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.

```json title="Arguments"
{ "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."

```text
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](https://tryace.dev/docs/concepts/memory#memory-and-operating-rules).

## Next steps

  - [Actions and approvals](https://tryace.dev/docs/concepts/actions-and-approvals): Set what Ace may change and who approves it.
  - [How memory works](https://tryace.dev/docs/concepts/memory): What Ace learns from incidents, alongside your rules.
  - [Ace MCP server](https://tryace.dev/docs/mcp): Give coding agents your rules and incident context.