Approval Gates and Human Review

Approval gates are triggered by the combination of action type and execution mode. In GOVERNED_PUSH mode, any AI-proposed change to live systems — publishing content, sending communications, updating records — requires explicit human approval before it executes. The trigger is defined by the action's risk classification, not by who initiated it.

Approval authority is role-based. Members and viewers can propose but not approve. Managers can approve within their scope. Owners and admins can approve any action within their organisation. Approval must come from someone other than the person who initiated the action — this is the four-eyes principle, and it applies to all consequential changes.

A rejected approval sends the action back to draft status with a rejection reason attached. The initiator can review the feedback, adjust the proposed action, and resubmit. Rejection is not a failure — it's the governance working. The rejection reason is recorded in the audit log and is visible to both parties.

The purpose of the approval gate is to ensure a human being is accountable for every consequential action. This accountability cannot be delegated to the AI, to a process, or to "the system said it was fine". If you're the approver, you are confirming that you have reviewed the proposed action and are satisfied it is correct, appropriate, and within scope. Sign off only what you've actually reviewed.