Your pipeline's four layers share one precondition and delivery refuses a human gate on every deploy - what do you change?

## The situation A build platform's four controls have been shown to rest on one fact — that this is a legitimate pipeline job, started and defined by someone entitled to do both. The technical fix is known: anchor one control on a precondition the job identity cannot inherit, which in practice means a different principal. The obstacle is not technical. The delivery organisation deploys many times a day, a human in the path of every deploy is a real cost they have already refused, and they are not wrong to refuse it. This is the layer of the problem a more senior technical answer cannot reach, and it is what the question is actually testing. ## Place the independence where consequence is, not everywhere Depth is not owed uniformly. Enumerate the steps a pipeline performs and ask which of them are irreversible or far-reaching: promotion into production, publishing an artifact other teams consume, minting or extending a long-lived credential, changing the pipeline's own permissions. Those steps are a small fraction of pipeline activity and they carry nearly all of the consequence. Put exactly one independent precondition on those steps. Every other job — build, test, preview, ephemeral environments — keeps running on the existing correlated controls at full speed. The layer count for the estate's most consequential action goes from one to two; the throughput cost lands on a few percent of runs. That asymmetry is the whole argument, and it is what makes the proposal acceptable rather than merely correct. ## What the independent precondition has to be It must be something the job identity cannot produce. In practice: an approval recorded by a **named human principal** who cannot start the job, plus a separation rule that the approver is not the author of the change. Two properties matter, and both get argued about: - **A different principal.** If the approver is any holder of the same repository role, you have added effort inside the existing precondition, not a new one. The population that may approve must not be the population that may define and start. - **Out of band from the job.** If the approval is recorded by something the pipeline itself drives, the job can produce it, and the inheritance is back. ## Making it survive contact with the organisation Three failure modes kill this control, and all three are organisational: 1. **It becomes a rubber stamp.** If the approver sees a step name and no context, they approve everything and the precondition is nominal. The approval has to show what changed in the definition and what the step will be able to reach. 2. **It cannot be got past during an outage.** A gate with no legitimate override is removed the first time it blocks a fix at three in the morning. Provide a break-glass path that is deliberately expensive and attributable to a person, and treat its use as a normal, occasionally correct outcome rather than a violation. 3. **Nobody owns the exceptions.** Teams will ask to be excluded, and some will deserve it. Someone with the authority to say no must own that list, and it must be re-read on a schedule; an exception granted once and never revisited becomes the estate's default. ## What you tell the delivery team The honest pitch is narrow and quantified in their currency: this applies to promotion only, it affects roughly this many runs a week, the median added wait is this, and here is the override. The wrong pitch is 'we need defence in depth', which invites them to point at four existing controls and ask what is wrong with them. The right pitch is that the four they have are one, that one is held for free by every contributor, and this is the smallest change that makes the number two. ## Say what you are accepting The pipelines that keep a single precondition are an accepted risk, not an unnoticed one. Name them, name who accepted them, and name the condition that would change the decision — a pipeline gaining production reach, or a contributor population growing beyond a size you are willing to trust as one principal. A principal-level answer ends with a written acceptance and a trigger, not with a claim that the estate is now layered. ## Answering it well Lead with the placement decision — one control, one class of step — then the different-principal requirement, then the two organisational conditions that keep it alive, then the explicit acceptance for everything else. If you find yourself proposing a gate on every deploy, you have answered the technical question and lost the negotiation.