# A Rule-Based DSL Over Object Metadata Is the Control Plane Icinga's design is a clean instance of a pattern that recurs far beyond monitoring: describe entities by attaching metadata, then express policy as rules that match on that metadata — and the rule layer becomes the control plane. The model is two steps. First *describe*: attach custom variables (strings, booleans, arrays, dictionaries) to objects. Then *express*: "it's a rule-based configuration, a custom DSL that lets you exactly express things like monitor MySQL on every database server which is in production but not located in Raleigh." Apply-rules auto-evaluate on every new object, and the same engine governs notifications ("alert John, but only during business hours"). Encoding policy once, declaratively, reduces human error across teams of mixed skill — a typo in a hand-edited config can break everything, so the web Director constrains inputs to validated option sets, and the config is versioned (git-style diffs, who-changed-what, rollback). The generative move is recognizing this is the *same shape* as policy rules gating agent actions: metadata-plus-match-rules is how you bind behavior to entities at scale, whether the entities are database servers or agent operations, and whether the verdicts are "monitor this" or "allow/deny this action." <!-- atomicity: 1 idea ✓ --> ## Why This Matters For **[[AI Agent Safety MOC]]**, this answers one of the MOC's open questions directly — *what's the analog of CEL rules for non-DB/non-HTTP agent operations?* Icinga shows the general form: a rule-based DSL over object metadata, with apply-on-match semantics, versioned and validated. The policy-as-code guardrail in [[3. Resources/Permanent Notes/Safe Agent Changes Come From Guardrails and Observability Not Trust]] (OPA-style enforced rules) is the same machine; Icinga is a 15-year-proven, ops-grade existence proof that the metadata-plus-rules control plane works at scale. It also sits next to [[3. Resources/Permanent Notes/Identity Is the Control Plane in Distributed Systems]]: identity says *who*, the rule-DSL says *what's allowed given the metadata*. Together they're the access and policy halves of the same control plane. ## Counterpoints to Hold - **A DSL is a second system to learn and to get wrong.** The "typo breaks everything" risk doesn't vanish — it moves up a level into the rule language, where mistakes are more expensive because they apply broadly. - **Declarative match-rules hide their interactions.** "Apply to everything matching X" composes in non-obvious ways; at scale the emergent behavior of overlapping rules is its own debugging surface. - **Proven for monitoring ≠ proven for agent safety.** Monitoring failures are observable and reversible; an allow/deny verdict on a destructive agent action has tighter tolerances than "did we alert the right person." ## Links - [[3. Resources/Permanent Notes/Safe Agent Changes Come From Guardrails and Observability Not Trust]] — policy-as-code is the same metadata-plus-rules machine applied to agent changes. - [[3. Resources/Permanent Notes/Identity Is the Control Plane in Distributed Systems]] — the *who* half; this is the *what's-allowed* half. - [[3. Resources/Permanent Notes/Bounded Action Spaces Not Better Models Make Agents Safe to Run]] — rules-over-metadata is one concrete way to express the bound on what an agent may attempt. ## Open Questions - What metadata do agent operations need to carry for an Icinga/CEL-style rule to make a good allow/deny verdict — and who attaches it reliably? - At what rule count does a declarative control plane become less auditable than the imperative checks it replaced? ## Source - [Reader: Icinga open source monitoring — Rules, scale, and Kubernetes](https://read.readwise.io/read/01kv3rzmz8ggynrjpp9e5x2ayg) — rule-based DSL over object metadata; apply-on-match; validated inputs; versioned config; push-based for K8s - See also: [[AI Agent Safety MOC]]