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

# Prompting an Operational Rule

> Tell the agent what is true about *your* environment

A [Specialty](/0.8/configure/specialties) shapes how the agent thinks about a domain. An **Operational Rule** tells it what is true in *your* environment and what that implies for its behavior.

<Note>
  Operational Rules are the **highest level of authority** in 2501. If a rule conflicts with a specialty or a ticket instruction, the rule wins.
</Note>

## Two kinds of rules

| Kind           | Use when                                                                                                                  | Example                                                                                                                                     |
| -------------- | ------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| **Constraint** | Something is unconditionally forbidden or required, regardless of context. Injected into every LLM call during execution. | "Resources tagged `Managed by Terraform` must never be modified directly via CLI or console."                                               |
| **Procedure**  | A recurring task has a *specific* process in your environment.                                                            | "To rotate a secret: retrieve from Vault at `secret/prod/<svc>`, generate per the secrets policy, update Vault, trigger a rolling restart." |

The specialty makes the agent a competent AWS operator in general. The operational rule tells it that in *your* AWS, Terraform-managed resources must go through a PR.

## Writing a good constraint

A constraint describes **what** is forbidden or required, plus **why**, so the agent can apply the spirit of the rule in situations you didn't anticipate.

```text theme={null}
Good:
"Resources tagged 'Managed by Terraform' must never be modified directly
via CLI or console. Changes must go through Terraform to prevent state
drift. If a direct change appears necessary, stop and report back, or
open a PR if the repo is at your disposal."

Good:
"Never restart auth-service and session-service simultaneously. They share
a Redis cluster and a concurrent restart causes a full session flush.
Always restart auth-service first, confirm healthy, then session-service."

Bad: "Be careful with production resources." — too vague to produce different behavior.
Bad: "Do not break things." — not actionable.
```

## Writing a good procedure

A procedure describes the **correct sequence of steps** for a recurring task in *your* environment. Only useful when your setup differs from standard practice.

```text theme={null}
Good:
"To deploy a service update:
  1. Verify current staging version with `kubectl get deployment <name> -n staging`.
  2. Apply the update to staging; confirm pods reach Ready state.
  3. Open a change window in the ITSM before touching production.
  4. Apply to production and monitor the deployment-health dashboard
     for 5 minutes before marking the task complete."

Bad: "Deploy carefully and make sure it works." — no steps, no specifics.
Bad: a procedure that describes how Kubernetes rolling updates work in general —
     the agent already knows this.
```

## What does NOT belong in an operational rule

| Out                                                 | Belongs in                                                                        |
| --------------------------------------------------- | --------------------------------------------------------------------------------- |
| General domain knowledge                            | [Specialty](/0.8/configure/specialties) — rules are for what's unique to your env |
| Infrastructure documentation, full service catalogs | A wiki — extract only the parts that change agent behavior                        |
| Judgment principles ("prefer incremental changes")  | Specialty                                                                         |
| How standard tools work                             | Tool definitions — the agent already gets those                                   |

Examples:

```text theme={null}
Bad in a rule:
"Kubernetes pods transition through Pending, Running, and Succeeded states." — agent knows this.

Good in a rule:
"Deployments are gated by a manual approval step named 'production-gate'.
You cannot bypass this step. If a deployment is stuck waiting for approval,
report back rather than triggering it directly."
```

## Scoping with tags

Rules are scoped with tags (OS, Type, Tech, Procedure, `app:*`). Tags drive matching: a rule with `os:linux` + `tech:nginx` + `procedure:restart` only applies to Linux nginx hosts on restart actions.

Two reasons to scope well:

* **Important rules reach the right tasks.** Tag matching is programmatic; the agent doesn't have to guess.
* **Irrelevant rules stay out.** A rule that doesn't match isn't injected, so the agent's context stays focused.

See [Operational Rules](/0.8/configure/operational-rules) for the full tag vocabulary and the matching trace.

## Maintaining rules

Rules go stale faster than specialties — they're tied to your infrastructure.

* **One rule, one concern.** A rule covering network policy + deployment + backup retention is three rules pretending to be one.
* **Include the reason.** A rule without a *why* gets worked around. A rule with one gets respected.
* **Review on environment changes.** A rule about a system that no longer exists is noise that degrades agent judgment.

```text theme={null}
Good:
"Do not run VACUUM on the billing database between 07:00 and 19:00 UTC.
It causes noticeable query latency for the payments team during business hours."

Weaker:
"Do not run VACUUM on the billing database during business hours."
```