> ## Documentation Index
> Fetch the complete documentation index at: https://docs.2501.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Operational Rules

> Guardrails that apply to the right tasks, not every agent

Operational Rules are directives that guide how agents execute tasks. Instead of injecting every rule into every agent, 2501 matches rules to each task based on what the task does and which host it targets. This keeps rules relevant, avoids noise, and lets you scope a guardrail precisely.

**Example:** A rule like "Always restart a service on the Linux web servers after editing its configuration" only surfaces on tasks that touch a Linux web server, rather than appearing for every agent in the organization.

> [!NOTE]
>
> Rules have no tags, and a host's technologies, applications and tags play no part in which rules reach a task. What a rule says decides where it applies.

## How matching works

Each rule is judged against the task by its name and description, and reaches the agent when it applies. A rule's scope is what it says: name the systems, hosts and actions it covers.

### Rules surface up front

For remediation tasks, the organization's relevant rules and procedures are surfaced at the **start** of the task, ranked by relevance to the task description. The agent has the applicable guardrails in hand from the beginning rather than only when its intent happens to match exactly.

## Managing Operational Rules

Go to **Command Center** → **Operational Rules** and click **Create Rule** to add a new entry. Open a rule from the list to edit it, or use the delete action on its row to remove it.

Rules extracted from a [Knowledge](https://docs.2501.ai/0.19/configure/knowledge.md) document show **Imported from knowledge** on their detail page, including the source section when available. Click **View import** to open the source document's Knowledge page. This link is available when you have permission to read Knowledge.

![Operational rule editor with version selector and Save Changes](https://mintcdn.com/2501/Nw-5R3i4HUHiTxUb/images/operational_rule_editor_019.png?fit=max\&auto=format\&n=Nw-5R3i4HUHiTxUb\&q=85\&s=ac0a38dfa25173ca5d53ff4e5b15e4b4)

Edit the rule's name and description, then save changes; earlier versions remain available in the version selector.

### Name

A clear identifier for the rule.

Example: `Restart services after config changes`

### Description

The directive itself, the guidance an agent should follow when the rule applies.

Write rules that are concise, specific, and focused on a single operational concern.

> [!WARNING]
>
> Overly strict or conflicting rules can prevent agents from completing tasks. Test new rules carefully before rolling them out broadly.

Example: `Always restart processes after updating their configuration files`

### Scope: organization or tenant

By default, a rule is scoped to the current organization. Pick **Scoped to Tenant** in the **Scope** selector to make the rule available to all organizations. Selecting the tenant scope requires tenant-level access; without it the selector stays on **Scoped to Organization**.

## Inspecting matches

Each task's detail page shows a **matching trace**: which operational rules were applied to the task and which were skipped. Use this to confirm a rule is reaching the tasks you expect and to debug rules that are too broad or too narrow.

## Best practices

Be specific in the text. Name the technologies, hosts and actions each rule actually applies to, so it surfaces only for the relevant hosts and actions. A rule left broad applies everywhere it can match, which adds noise and risks an irrelevant rule getting in the agent's way.

Keep rules outcome-focused rather than command-specific where you can, and review rule effectiveness regularly using the matching trace.

Use [Blacklist](https://docs.2501.ai/0.19/configure/blacklist.md) to hard-block prohibited commands, and Operational Rules to guide behavior. Combine with [Specialties](https://docs.2501.ai/0.19/configure/specialties.md) for domain workflows.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.