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

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

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 with tags

Maintaining rules

​Two kinds of rules

​Writing a good constraint

​Writing a good procedure

​What does NOT belong in an operational rule

​Scoping with tags

​Maintaining rules

Two kinds of rules

Writing a good constraint

Writing a good procedure

What does NOT belong in an operational rule

Scoping with tags

Maintaining rules