Approvals: pausing before an action

Some steps should not happen without a person saying so. A Play can declare a human approval gate, and when a run reaches that step it stops, keeps what it was about to do, and waits.

What the gate does

The run executes everything the gated step is allowed to do beforehand, saves the material to be reviewed, and moves to awaiting approval. Nothing with an effect outside YAMO happens until somebody decides. The run is not finished and not failed; it is held.

An approver sees the held document in full, and has two choices.

• Approve and continue. The run resumes from its own saved state and carries on from where it stopped.
• Reject. The run stops, visibly and permanently, with the reason kept alongside it. A rejected step is not quietly rewritten and continued.

Either decision is recorded once, with who made it and when. A second decision on the same gate is refused rather than applied.

Approving is not the same as succeeding

This distinction matters more than it sounds.

Approval is permission to proceed. It is not evidence that the send, the post or the change afterwards actually worked. After approval the runtime carries out the action and records honestly whether it succeeded. A run never reports a successful send because somebody approved the message.

Where the decision is made

In the builder, on the Playbook the run belongs to, in the outputs rail. Not in the email: the notification tells you a run is waiting and links you to the review, and it deliberately carries no approve or deny button. Notify, never gate.

A schedule cannot bypass a gate, a retry cannot, and a worker restart cannot.

Declaring one

A gate is part of a Play in the Playbook's own document. There is no control in the builder for adding one today. The capability is live and every gate a definition declares is honoured, but the authoring surface was deliberately withdrawn while the design is settled, so in practice a gate exists where a Playbook shipped with one.