Prompting an Operational Rule

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. Enable Always inject to deliver it on every Job, Task and action-verifier request.	”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. Use Always inject mainly for security constraints. Keep them few and concise because they occupy context on every request. Leave task-specific rules on relevance-based selection.

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

Examples:

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 a rule

Unless Always inject is enabled, 2501 selects rules by matching their name and text to the task. State where each rule applies: “Before restarting nginx on the Linux web servers, run nginx -t” applies to nginx restarts on those servers. Two reasons to scope well:

Important rules reach the right tasks. A rule that names the system and the action it covers is found by the work that mentions them.
Irrelevant rules stay out. A rule that doesn’t match isn’t injected, so the agent’s context stays focused, unless Always inject is enabled.

See Operational Rules for 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."

Prompting

Best Practices

Risk & Safety

FAQ

Prompting an Operational Rule

Two kinds of rules

Writing a good constraint

Writing a good procedure

What does NOT belong in an operational rule

Scoping a rule

Maintaining rules

​Two kinds of rules

​Writing a good constraint

​Writing a good procedure

​What does NOT belong in an operational rule

​Scoping a rule

​Maintaining rules

Two kinds of rules

Writing a good constraint

Writing a good procedure

What does NOT belong in an operational rule

Scoping a rule

Maintaining rules