Who approves widening a shared licence-policy rule's allowed list, and what does that silently re-open?

## Two instruments that look the same from the outside A team is blocked. They ask for a licence to be added to the allowed list your rule reads. From their side it is a small data edit. From yours it is one of two very different things: - **A scope change.** The organisation, or that unit, now accepts this licence class. It applies to everyone reading that parameter set, to everything they have already shipped, and to everything they ship in future. - **An exception.** This one artifact is allowed through despite the rule, with a reason, and the rule is unchanged for everyone else. The interview question is whether you can tell them apart under pressure, because the cheapest thing to do - edit the list - is the one that quietly does the most. ## Why widening is retroactive and silent A parameter is not applied at approval time; it is read on every evaluation. Add an entry and, from the next run, every artifact in every repository consuming that set is judged against the wider list. Nothing announces this. Nobody re-approves the artifacts that now pass. In particular: - Anything a reviewer previously **denied** on that basis now passes, without the denial being revisited. - Anything currently carrying a scoped exemption for that entry no longer needs one, so the exemption becomes invisible - it will sit in the register unused, or be tidied away, and the fact that something needed relief at all disappears from the record. - Artifacts nobody has ever examined pass too, because they were never in the conversation. That is the sense in which a parameter widening re-opens exceptions nobody re-approved. The organisation did not decide to accept those cases; it decided to unblock one team, and the mechanism did the rest. ## Make the delta the artifact under review The strongest operational move is to stop reviewing the list diff and start reviewing its effect. Re-evaluate the current inventory - every artifact and its bill of materials - under both the existing and the proposed parameter set, and produce the set of decisions that flip. "This adds one licence to one list" and "this changes 140 artifacts across 30 repositories from deny to allow, including these four that were explicitly denied last quarter" are the same diff and completely different decisions. Attach the delta to the change and require it in review. Where the estate is large enough that this is slow, it is still the right thing to run nightly and attach to the request. ## Who decides Three parties have a legitimate claim, and conflating them is how this goes wrong: - **The rule's owner** owns the logic and the shape of the parameter - what the list means, what belongs in it structurally. They are not the right people to decide the organisation's licence appetite. - **The accountable owner of the parameter set** - the business unit or function whose risk it is - owns the value. If the set is per-unit, that owner is identifiable; this is one of the strongest arguments for per-unit sets over one global list. - **The subject-matter authority** - for licences, whoever actually owns licence policy - owns whether the class is acceptable at all. A platform team should not be inventing that answer under deadline pressure at 5pm. The common anti-pattern is that the platform team, being the ones with write access to the rule repository, becomes the de facto approver of decisions it has no standing to make - and simultaneously the bottleneck everybody resents. Push the value decision to the accountable owner, keep the mechanism decision with the rule owner, and make both visible in a review on the parameter file, which lives in the rule repository and goes through the same review and tests as the logic. ## The constraint on the other side All of this pushes towards more parameter sets: give every unit its own so the blast radius is small and the owner is obvious. Taken far enough that reproduces the problem parameterisation was meant to solve - dozens of sets, drifting, each an unreviewed policy of its own, and no way to say what the organisation enforces. So the library needs a stated limit: a defined axis along which sets may vary (business unit, or data classification, or environment - pick one), a named owner per set, a periodic review that asks whether each set still needs to differ, and a default set that new consumers inherit unless they justify their own. Variation should be legible in one file; the day you cannot read the organisation's actual policy off that file, the parameterisation has stopped paying for itself. ## What to say when the team is blocked at 5pm Separate urgency from scope. The team needs to ship tonight; the organisation does not need to change its licence policy tonight. Grant the narrow, time-boxed relief for the artifact in front of you through whatever exception path exists, and open the widening as a separate decision with a computed delta and the right approvers, on a normal timescale. Doing it in the other order - widen now, review later - means the review never happens, because the pain that would have driven it is gone.