A platform team's policy-as-code library has 240 rules. 190 are warn-only because teams objected to blocking. Pipeline output runs to 300 lines and nobody reads it. Two recent incidents were caused by conditions that rules 14 and 87 had been warning about for months. Review this. What would you remove, what would you change, and what would you keep?

What is actually required

The library exists to prevent a known set of bad outcomes: an unencrypted store, a publicly exposed endpoint, a workload with no limits, an image from an unapproved registry. The requirement is prevention, and a warning prevents nothing. Two incidents caused by conditions that were being warned about is not a communication failure; it is the predicted outcome of a control with no enforcement.

What I would remove

• Every warn-only rule, as a category. Each one is either important enough to block or not important enough to print. Go through the 190 once: promote the ones that name a real consequence, delete the rest. In practice a 240-rule library collapses to 30 to 50 blocking rules, and the deletions are mostly stylistic preferences that were never conformance rules.
• The 300-line output. A gate should say nothing when it passes and print one actionable finding when it fails, with the fix. Output nobody reads is worse than no output, because it teaches the team that this channel does not matter — and that lesson applies to the blocking rules too.
• Rules that duplicate a platform default. If the base template already sets resource limits and the registry, a rule checking it is testing your own scaffold. Test the scaffold in the scaffold's pipeline once.

The one change that matters

Make blocking possible by making exemptions legitimate. The reason 190 rules are warn-only is that someone objected and warn-only was the compromise available. Replace it with a time-boxed waiver: a team can proceed with a named owner, a stated reason and an expiry — 30 or 90 days — recorded in a place that is reviewed. Then a rule can block, because there is a route through it that is not a fight.

This is the whole design. A gate with no exemption path becomes warn-only or gets deleted; a gate with an unlimited exemption path is warn-only with extra steps. The expiry is what makes it a control.

What I would keep, even though it looks odd

• The two rules that were warning. They were right. Promote them first and say publicly that they were right, because that is the argument for the rest of the change.
• A small set of warn-only rules for genuinely new policy, on a stated ramp: two weeks of warning, then blocking on a published date. Warning is a legitimate transition state and an illegitimate destination.
• Evaluation at more than one point. Rules in the pipeline give fast feedback; the same rules at admission catch what bypasses the pipeline, which is the gap that makes pipeline-only policy an illusion. Keep both, and keep them generated from one source so they cannot drift.

How I would argue this in the review

With the two incidents, in order. "These rules told us, and we had built a system in which being told means nothing." That reframes the discussion from teams-versus-platform to a shared defect. Then bring the trade explicitly: 190 warnings become roughly 40 blocks plus a waiver you can get in an hour, which is a reduction in noise and an increase in enforcement at the same time. Teams generally accept that trade, because the thing they objected to was being blocked with no way through, not the rule.

When this is the wrong answer

In an organisation of three teams, 40 blocking rules is bureaucracy — a checklist in a pull-request template and a shared base template gets most of it. And where a rule genuinely cannot be decided by a machine, such as whether a data flow is proportionate, do not force it into the engine: a machine-checkable standard and a human review forum answer different questions, and the mistake in both directions is expensive. Choose the engine for unambiguous rules and the forum for judgement, and keep the engine's output short enough that someone reads it.