When should a family of near-copy policy rules become one parameterised rule?

## The problem: a family of near-copies Rule libraries grow near-copies the way codebases grow copy-pasted functions. A licence rule is written for one business unit, a second unit needs the same check with a slightly different accept-list, and by the ninth copy you have nine ids, nine sets of tests, nine review threads and one bug that was fixed in four of them. Every one of the nine is subtly free to drift, and drift in a guardrail is invisible: the copies all pass their own tests, so nothing tells you that three units are enforcing a rule the others quietly stopped enforcing. The fix is to notice that the nine differ in **data**, not in **logic**, and to make the data an input. ## What parameterising actually buys - **One place to fix the logic.** A bug in how the rule reads a licence expression is fixed once and every unit gets it. - **One id.** Waivers, suppressions, control maps and dashboards all key on a single stable name, so "how often did this guardrail fire across the estate" is one query rather than nine unioned ones. - **One review.** Changing the check is a code review of a rule; changing what a unit accepts is a data review of a parameter set. Those are genuinely different decisions with different reviewers, and separating them is a feature. - **A visible difference.** With nine copies, the difference between units is buried in nine files. With one rule, the whole variation across the organisation is a single readable data file. ## The test for whether a family should collapse Ask what actually differs between two candidates: | What differs | Verdict | |---|---| | A value the rule compares against - a list, a threshold, a set of allowed names | Parameterise | | The field the rule reads on the same document | Usually parameterise, if the meaning is the same | | The message shown on denial, and the fix the person must make | **Separate rules** | | Which branch of the logic runs at all | **Separate rules** | The third row is the one people get wrong, and it is the whole reason this is a judgment question rather than a refactoring exercise. A rule that denies a copyleft licence in a distributed binary and a rule that denies an unrecognised licence expression may compare against the same list, but the person who trips them needs entirely different advice: one has to swap a dependency or get a legal exception, the other has to fix the metadata their build produced. Merging them yields one denial message that is vague enough to cover both, which means it helps neither. **A parameter must not absorb near-copies whose denial message and remediation genuinely differ.** ## The mode-switch smell The failure mode of enthusiastic parameterisation is a parameter that stops being data and becomes control flow: a boolean like `strict`, an enum like `mode`, a flag that says which of two shapes the rule should check. The giveaway is that the two paths are never exercised together - no consumer runs both - so the tests for one path do not protect the other, and a change made for one unit ships to a unit that never asked for it and never runs that branch. When you see it, split the rule and give each half its own id, its own message and its own tests. A second smell is a parameter with a default that most consumers never set. A default is a policy decision made silently for everyone who did not read the file, and when it is later tightened, every unconfigured consumer changes behaviour at once. ## Collapsing an existing family without losing exemptions The migration is where this gets sharp, because the nine old ids are already referenced from outside the library. A safe collapse looks like: publish the new parameterised rule alongside the old nine; run both and compare decisions on real inputs until they agree; inventory every waiver and suppression keyed on the nine old ids and re-issue them against the new id **before** the old rules stop being emitted; mark the nine ids retired rather than deleting them; and never mint a new rule under any of the nine names. Skip the inventory step and you get the quiet version of the failure - exemptions that still sit in a register, still look active, and exempt nothing.