A Specialty 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.
Operational Rules are the highest level of authority in 2501. If a rule conflicts with a specialty or a ticket instruction, the rule wins.
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.” |
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.
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.
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 — 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 |
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."
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 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.
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."
