Release Interlocks

In railway engineering, an interlock makes the unsafe movement impossible — the signal cannot clear while the track is occupied. Not forbidden: impossible, by construction.

A release needs the same construction. Some operations are irreversible, some are legally binding, and some require judgment.

These are the three interlocks that keep any automation from taking those acts alone:

Interlock	Guards against
Never upload without asking	Irreversibility
Never accept a PLA	Legal binding
Never advance a gate	Hollowed-out judgment

Never upload without asking

When a build is uploaded to Google Play or TestFlight, its version and build number (say 2.21.0+84) are consumed forever. The stores will never accept another build with that number, even if the upload was a mistake. There is no undo.

So the automation can build the artifact, verify it, and line everything up. The act that burns something permanently is never taken on its own initiative.

The nuance is in two parts:

• The lane may run, your word starts it. Your “run the upload live” is the upload decision; the lane is just your hands.
• Approval never carries forward. Approving the staging upload does not pre-approve the production one. Each burn gets its own yes.

Never accept a PLA

The PLA is Apple’s Program License Agreement, an actual legal contract. Apple updates it periodically, and until someone clicks “agree,” builds mysteriously fail to export.

The tempting automation move is to detect it, click accept, and unblock the pipeline. That is forbidden: clicking accept is entering a contract on your behalf. The split:

• The automation may detect the block, explain it, and tell you where to go (developer.apple.com).
• The automation never signs for you. Same category: issuing or renewing signing certificates, which are your cryptographic identity with Apple.

Never advance a gate

A gate is a checkpoint whose entire value is that a human consciously said yes at that moment:

• “I installed the staging build and it works.”
• “This store copy is what I want customers to read.”

The failure mode here is not the automation doing something forbidden. It is the automation doing something reasonable: “the tests passed, I’ll continue.” The moment it infers a yes instead of receiving one, the gate still exists on paper but protects nothing.

So the rule is absolute: a gate is passed by your words, never by the automation’s confidence. No artifact or log can prove you looked at the screen, which is why on-device verification is always asked, never inferred.

The pattern

The split is one line:

• The automation owns everything mechanical and reversible: building, checking, drafting, diagnosing.
• You own everything irreversible, legal, or judgment-based.

It is the same logic as a good assistant with your credit card saved: they can fill the entire cart, compare prices, and have the order ready — but you press “buy.” Not because they are untrustworthy, but because the accountability for that click cannot be delegated, and a well-designed system never pretends it can.