Quality Gate Threshold
The specific numeric bar a change must clear, and the perverse incentives it creates when chosen carelessly.
Thresholds are where measurement turns into behaviour, and the behaviour is frequently not the one intended — a direct case of Goodhart's law inside an engineering pipeline.
A coverage threshold produces tests written to touch lines without asserting anything. A defect count target produces defects reclassified as change requests. A build duration target produces tests moved out of the gating suite. In each case the number improves and the underlying property does not.
Two design choices reduce this. Gate on deltas rather than absolutes — coverage on changed lines must not fall, new critical vulnerabilities are blocked while the existing backlog is worked down on a plan — which makes the gate achievable for legacy code and targets it where behaviour can actually change. And gate on a small number of properties tied to real consequences rather than on a dashboard of everything measurable.
The governance point for anyone setting these centrally: a threshold applied uniformly across services of wildly different risk profiles is either too weak for the payment service or too strict for the internal admin tool, and usually both at once. Tier the requirement by consequence, and make the tiering explicit.