Preventive Control Placement
Choosing where in the lifecycle a control acts — at authoring, at admission or after the fact — which determines both its strength and its cost.
The same requirement can be enforced at three points, and the choice matters more than the rule. In the editor or pull request, it is fast feedback and easily bypassed. At admission, it is authoritative and blocking. After deployment, it is detective — it tells you the exposure existed.
The trade is between certainty and friction. Admission-time enforcement is the only one that guarantees the non-compliant state never existed, which is what matters for controls where the exposure window is the risk. It is also the one that stops work, so it must be fast, correct and rarely wrong, or it becomes the thing everyone routes around.
The strong pattern is to place the same rule at more than one point with different severities: advisory in the pull request so the author fixes it while they still have context, blocking at admission so it cannot reach production, and detective afterwards so drift and exceptions are visible. What does not work is choosing only the detective placement and describing it as a control, which is the most common arrangement and the weakest.