How do you review a policy rule you cannot follow well enough to confirm it matches the written standard?

## What you are actually signing When you approve a policy rule you are not saying *this looks like working code*. You are attesting that the executable rule and the written standard say the same thing. That attestation is the only link between the paragraph an auditor reads and the check that runs on every change. If you cannot follow the rule, you cannot make that link, and approving anyway breaks the chain quietly — everything stays green, and nobody finds out until the rule is tested by a real incident or a real audit. So the first move is to say the boundary out loud, without making it about the author: *I can see this passes its tests; I cannot confirm it enforces clause 4.2, so I cannot approve it in this form.* ## Reviewability is a property of the rule The unproductive version of this conversation treats readability as taste — my preferences against yours. It is not. A guardrail is a control, and a control that only one person understands has a single point of failure who will eventually change teams. Concretely, an unreviewable rule costs you: - **Attestation.** No second person can confirm what it enforces, now or a year from now. - **Change.** Nobody dares modify it, so when it misfires the team routes around it with an exception instead of fixing it. - **Drift.** When the standard is revised, nobody can tell which part of the rule corresponds to the revised clause. That is the outcome to name in the review: not *this is ugly*, but *this becomes a control on paper*. ## The three things to ask for **1. Named intermediate steps.** Ask the author to decompose the rule so each named piece corresponds to one clause of the standard. A rule expressed as *the multi-replica workloads*, *the budgets covering a label set*, and *a workload with no covering budget* can be reviewed line by line against the paragraph. The same logic as one nested expression can only be reviewed by holding it all in your head at once. **2. A case the rule must reject.** Obvious, and usually present. **3. A case the rule must *not* flag.** This is the one that gets skipped, and it is the one that catches the most dangerous defect: a rule that is silently vacuous. A rule whose condition never matches anything reports zero violations for every input. It passes the whole existing repository, it produces a clean report every quarter, and it enforces nothing. The allow-case fixture is what proves the rule is looking at something. ## When passing tests are offered as the answer Authors often respond that the test suite is green. Tests show the rule agrees with the fixtures someone wrote — usually the same person who wrote the rule, thinking about the same cases. Review asks a different question: does the rule say what the *standard* says, including for inputs nobody thought of. Both are needed, and neither substitutes for the other. ## When the rule cannot be made readable Sometimes the author is right that no clearer version exists in the style they are using. Take that as information about the language, not about them. If the requirement needs quantification across objects and a join, and the house style offers only single-object shape matching or a single expression, then the readable version lives in a style that can name intermediate results. Three outcomes are legitimate: - move this one rule to the style that fits, if the platform keeps such an escape hatch; - ship a deliberately narrower rule and record in the standard exactly what it does and does not check; - do not ship a rule at all for this clause, and handle it by review or detection instead, honestly recorded as such. All three are better than the fourth option, which is merging something correct and opaque and calling the control implemented. ## How to write the review comment Keep it about the artifact and the standard. Quote the clause, point at the part of the rule you cannot map to it, and say what would let you approve: a decomposition, the two fixtures, or a note in the standard describing the narrower scope. Offer a pairing session rather than rewriting it yourself — the author keeps ownership, and the rule that comes back is one that two people can read. ## What good looks like afterwards A rule you can hand to somebody who has never seen the policy repository, next to the paragraph it enforces, and they can tell you within a minute whether the two agree. That is the bar. Every property people actually want from policy as code — audit evidence, safe change, shared authorship — is downstream of it.