Which rule-language style should a platform team standardise on for its policy guardrails?

## The question behind the question Asked as *which language*, this sounds like a tooling preference. It is a staffing and governance decision: the style you standardise on determines who can author a guardrail, who can review one, how fast a rule can be changed after it misfires, and which requirements you are simply unable to encode. Answer it in those terms. ## Start from the distribution of rules, not the hardest one Inventory the guardrails you actually need. In most estates the distribution is lopsided: the large majority are assertions about a single object — a required field, a forbidden value, a value inside a permitted set — and a small minority are relations across objects, such as *every workload with more than one replica must be covered by a PodDisruptionBudget*. The common mistake is to choose for the hardest rule in the backlog. That picks the most expressive style for everything, and pays its review cost on the hundred simple rules that did not need it. Choose for the bulk, and handle the minority explicitly. ## What the restricted styles buy A declarative match document is written in the same serialization as the object it judges, so an engineer who knows the resource can read the rule without knowing the policy system. A restricted expression language adds computation while keeping strong guarantees: no I/O, no side effects, no unbounded iteration. Those are not arbitrary limitations — they mean evaluation terminates by construction and the cost of a rule can be reasoned about before it is allowed onto the path of every change. A rule that runs on every change is infrastructure, and infrastructure whose worst case you cannot bound is an outage waiting for the right input. The price is the ceiling described above, plus the fact that a single expression has nowhere to name an intermediate result, so complexity shows up as nesting. ## What the expressive style buys, and what it costs A logic language can quantify, join across objects, and — crucially — name intermediate results so each name lines up with a clause of the written standard. For the rules that genuinely need it, it is not merely more powerful but more *readable* than the same logic crushed into one expression. Its cost is a second skill set. Fewer engineers can author it, fewer can review it, and its evaluation-cost story is weaker. Adopt it as a bounded escape hatch — an explicit list of rules that live there, with a named owner — rather than as the house style, and re-examine it if the list keeps growing. ## XACML's lesson XACML is an XML-based, attribute-oriented policy language standardised by OASIS, with policy sets, policies and rules, combining algorithms such as deny-overrides and first-applicable, and decisions of Permit, Deny, NotApplicable or Indeterminate. As a design it is extremely general: it can express almost any access rule you can describe. The lesson is not that it was a bad idea, but that generality was bought with a shape people could not work with. The artifacts were long XML documents that few engineers hand-authored and fewer read in review; authoring moved into specialist tooling, and the policies became something you trusted a tool to produce rather than something a colleague checked. Expressiveness that nobody exercises is not expressiveness — it is a maintenance surface. Any modern choice should be tested against the same question: can a second engineer read one of these rules and tell me it matches the standard? ## Making the decision concretely - **Count the rules that need quantification.** If it is a handful, the escape hatch is right. If it is a third of the backlog, choose the expressive style as the house style and accept the training cost. - **Count the reviewers.** How many people must be able to approve a guardrail for the review queue not to become one person? That number caps how exotic your style can be. - **Fix a traceability rule.** Each rule names the clause it enforces, and rules narrower than their clause say so. This is what makes the style change survivable later. - **Decide the cost story.** Whatever runs in the path of every change must have a bounded worst case, and a rule that cannot demonstrate one does not go there. - **Cap the count of styles at two.** Three styles means no reviewer is fluent in the one in front of them. ## How to answer in an interview Say there is no context-free answer, then give the decision procedure: the distribution of rules decides the default, the number of competent reviewers caps the expressiveness, bounded evaluation is non-negotiable on the hot path, and one escape hatch is kept with a named owner and an explicit list. Close with the failure you are steering away from — a language so general that rules become artifacts only a tool can produce and no colleague can check.