Before deciding#
- Open Approvals or the Approvals tab on the awaiting run.
- Read the plan, target, resolved source revision and current policy requirements.
- Confirm you are an eligible approver. Protected decisions can require a current MFA-authenticated human session and recent reauthentication.
- Check whether the initiator or source committer is excluded by separation-of-duties rules. Use another eligible person when required.
Record a decision#
- Choose Approve or Reject on the run.
- Enter the reason. Rejection requires a reason; include a concise explanation that the project owner can act on.
- Submit and inspect the recorded decision.
- If multiple approvals are required, wait for the remaining eligible decisions. One approval does not necessarily release the run.
- After the gate opens, follow apply and verification. Approval is permission to proceed, not proof the deployment succeeded.

Stale and rejected decisions#
| Response | What to do |
|---|---|
| stale_approval | Refresh the run. The current plan, target, live-state or policy evidence no longer matches the decision. Review the new evidence. |
| approval_expired | Re-evaluate the policy/plan through the supported run flow. Do not reuse an expired decision. |
| separation_of_duties | Have an independent eligible approver decide. |
| strong_authentication_required | Complete current MFA and recent reauthentication with a human account. |
| approval_already_decided | Inspect the existing decision; repeated submission is not an additional independent approval. |
API-key limitation#
An API key is useful for permitted automation, but it is not a current MFA-authenticated human session. Do not design an automation that silently substitutes an API key for a protected human approval.