Skip to main content
Approval sits between admission and permission in the action lifecycle: the world acknowledges the submission immediately with state: "pending_approval", then waits for a decision before the action becomes accepted. The admission bound (AWP-LIF-002) applies to the acknowledgement, not to the decision.
  • Action types marked requires_approval: true enter the pending_approval state after validation and before accepted. The world emits safety.approval_requested (approval id, action id, type, params, requester, expiry, and the current task when one is set) on the approval channel to its configured approver(s). [AWP-APR-001]
  • The approver responds via safety.approval.respond (approve | deny). Approve → accepted (or queued if the concurrency group is busy and the submission chose queue). Deny → rejected with reason approval_denied. [AWP-APR-002]
  • Approvals time out after approval_timeout_ms (safety policy; default 60000) → rejected with reason approval_timeout. If the submission’s own deadline_ms expires first, the action is rejected with reason deadline_exceeded (AWP-LIF-008). [AWP-APR-003]
  • Approvals are per-action; worlds MAY support scoped standing approvals (type + parameter predicate + expiry), which MUST appear in the audit log. [AWP-APR-004]
  • Who may approve is deployment configuration, out of protocol scope; the protocol only defines the messages and states. [AWP-APR-005]
  • Approval request content is subject to the audit redaction rules (AWP-AUD-006): params fields and the task text listed in safety_policy.audit.redact_paths are redacted in the log, not in the message to the approver. [AWP-APR-006]