Significant-Minority Trigger

A pipeline with human approval on every change becomes the throughput ceiling: fixed capacity against unbounded demand, a queue that grows, and teams that find routes around it. An approval that is always granted is a delay with the appearance of a control.

A pipeline with no human approval at all is unacceptable in most regulated contexts and is genuinely unwise for a small class of changes.

The trigger resolves it by defining, in advance, which changes are in that class.

Why it must be a rule

Left as a judgement, the reservation collapses in both directions. Under delivery pressure everything is deemed routine; after an incident everything is deemed significant. Neither is a policy, and both are decided by whoever is most anxious at the time.

Implementation patterns

Typical triggers — stated as conditions the pipeline can evaluate or that an author can apply unambiguously:

• A change to a security boundary — authentication, authorisation, encryption, network exposure.
• A data migration touching customer records, particularly one that is not reversible.
• A change to a regulated calculation — pricing, interest, tax, fees — where consistency across customers is a fairness or regulatory matter.
• A first deployment of a new component, or a change to routing and tenancy placement.
• Anything the risk function has explicitly named.

Everything else goes through automated gates plus progressive delivery, where the safety comes from small changes, fast rollback and automated halt conditions rather than from approval.

Industry example

Regulated fintechs such as Groww and testing platforms such as BrowserStack both reach the same conclusion from opposite directions: the first because the risk function demands demonstrable control, the second because volume makes approval impossible. Both end with automated gates producing evidence as a by-product and a narrow, stated human-review class.

The argument that persuades a risk function is that automated controls prevent rather than detect, operate identically on every change — the property manual review cannot claim and sampling exists to test for — and run in seconds so no queue forms to cause bypass.

Failure scenarios

• No trigger, so approval is either universal or arbitrary.
• A trigger phrased as a judgement ("significant changes"), which is not a rule.
• The trigger expanded after every incident until it covers everything.
• Approval with no defined criteria, so the approver decides on intuition and the control cannot be assessed.
• The automated gates not producing evidence, which loses the strongest argument for the arrangement.

Trade-offs

A rule will occasionally classify a genuinely risky change as routine, and that change will ship without human attention. That is a real cost, and the mitigation is progressive delivery with automated halt rather than a wider trigger.

The counter-evidence is that higher deployment frequency with smaller changes correlates with lower change failure rates — so widening the trigger to catch more risk reduces frequency and, on the data, increases failure. That is the counter-intuitive finding worth bringing with the numbers rather than as an assertion.

Interview question

"Your risk function wants approval on every production change. Write me the rule you would propose instead, and tell me what evidence you would bring to the conversation."