Rules
A Rule is a piece of standing guidance you write that shapes how an AI Assistant interprets findings. Rules do not change what data the assistant collects — tasks still run the same way — but they change what the assistant treats as noise, what it treats as signal, and how it phrases the result.
Rules are RunWhen’s primary mechanism for moving an assistant from “generic infrastructure expert” to “engineer who understands your environment.”
Why Rules exist
Telemetry is uniform; environments are not. The same Kubernetes event can mean very different things in different places:
- A
NodePressurewarning is a routine cost-saving signal in a spot-instance lab cluster, but a paging-worthy event in a customer-facing region. Back-off restarting failed containeris normal during a planned rollout but actionable any other time.- Flux reconciliation drift is interesting in production and uninteresting in a sandbox where developers push frequently.
Without Rules, an assistant has to either flag every finding (overwhelming) or guess at relevance (incorrect). Rules let your team encode “here, this means X” in plain language, once.
What Rules can shape
Three families of behavior change cleanly with Rules:
| Behavior | Example rule intent |
|---|---|
| De-noise | Acknowledge expected events (lab preempts, scheduled maintenance, known transient errors) and deprioritize them in responses. |
| Re-prioritize | Tell the assistant which categories of finding to lead with — for instance, application-layer issues over infrastructure noise in a developer-facing namespace. |
| Reframe | Adjust how the assistant phrases findings — for example, always pair an OOMKilled finding with the team’s rollback procedure, or always cite the on-call runbook for database-connection issues. |
A Rule does not control which tasks run (that is the assistant’s confidence thresholds — see AI Assistants) or what procedures users invoke (those are Commands).
Scope: who a Rule applies to
Rules attach to a scope in the workspace’s hierarchy. Three scope levels matter conceptually:
- Workspace-wide — applies whenever any assistant in the workspace investigates anything. Use for environment-wide truths (“this cluster runs on spot instances”).
- Per-assistant — applies only when a specific assistant (e.g., a conservative auto-responder) is the one investigating. Use to give different personas different interpretive lenses without forking your task library.
- Per-user — applies when a specific user is interacting. Use sparingly: this is mainly for individual preference tuning, not core operational truth.
Scope answers “when does this guidance fire?”. Use the narrowest scope that still covers the cases you need.
Where Rules sit in operational context
Rules are one of three levers your team uses to make an assistant feel like it belongs in your environment. The three levers are conceptually distinct:
| Lever | Shapes | Example |
|---|---|---|
| Rules | Interpretation of findings | ”Treat node-pressure events in lab-* clusters as background.” |
| Commands | Procedure — repeatable investigation flows | /investigate-namespace runs the same set of checks every time. |
| Knowledge | Context — narrative facts telemetry cannot supply | ”The payments team owns checkoutservice; on-call is paged via #pay-oncall.” |
The Building Operational Context guide shows how to combine all three over time.
Anti-patterns
- Encoding investigation steps inside a Rule. That belongs in a Command.
- Encoding ownership/architecture facts inside a Rule. That belongs in a Knowledge note.
- Writing many narrowly-scoped per-user Rules instead of fixing the underlying noisy signal. Rules are interpretive, not a way to silence broken health checks.
Where to use this in the UI
For the in-product workflow — creating, editing, scoping Rules in the UI — see Use → Workspace Studio → Rules.