Human approval gate

Problem Context

• An agent, workflow, deployment, rule, model, integration, or scheduled automation has reached a step that can send messages, spend money, change access, publish content, run tools, deploy code, delete data, update legal status, or affect customers.
• The system can identify the exact step, payload, run state, prior steps, approver rule, current input version, model or workflow version, freshness, and downstream consequence.
• Approval may be required because of risk threshold, policy, low confidence, source gap, high cost, external side effect, customer impact, compliance, security, or manual separation of duties.
• The human decision must affect whether the next automation step runs now, runs with edits, is canceled, is retried, is escalated, or is overridden.
• The gate can appear in agent consoles, workflow run pages, deployment screens, service desks, content operations, finance tools, and mobile approval notifications.

Selection Rules

• Choose human approval gate when automation is paused at runtime and cannot execute the next step until an eligible human authorizes it.
• Use approval workflow when a submitted request needs a durable multi-state approval route independent of a currently paused automation run.
• Use review queue when users triage many queued items rather than decide one armed automation checkpoint.
• Use review before submit when the initiating user is checking their own answers before committing a transaction.
• Use recommended next action when the system suggests an optional next step; use human approval gate when policy or runtime safety requires human authorization.
• Use confidence / uncertainty display inside the gate when reliability affects the decision, but do not let confidence replace the approval decision.
• Use source grounding display or citation display inside the gate when evidence affects approval, but keep the gate responsible for pause, authorization, and resume.
• Show the exact action, payload, target, prior run context, and resume consequence before the human can approve.
• Block approval when the run state, payload, source scope, model version, permissions, risk threshold, or approver eligibility changed after the gate was opened.
• Do not treat post-action audit, passive notifications, or vague pending labels as an approval gate.

Required States

• Paused gate state with proposed action, payload snapshot, reason for gate, and run context.
• Eligible approver state with role, separation-of-duties rule, and decision controls.
• Not eligible or self-review-blocked state with request-access, delegate, or escalation path.
• Approve and resume state that revalidates freshness before executing the gated step.
• Reject or cancel state that stops the step and records reason and fallback.
• Edit before approve state that changes the proposed payload and requires revalidation.
• Timeout, expired, due soon, and escalated gate states.
• Stale gate state when input, payload, source, model, policy, or workflow version changed.
• Bypass or emergency override state with elevated permission and audit reason.
• Resumed, completed, failed after approval, and rolled-back states.
• Mobile compact approval state that still shows action, risk, payload, approver rule, and timeout.

Interaction Contract

• The gate belongs to a specific automation run, step ID, payload version, model or workflow version, target object, and approver rule.
• Approval is valid only for the displayed snapshot and must re-check run state, payload hash, eligibility, source freshness, policy, and threshold immediately before resume.
• Approve resumes the named gated step and does not authorize unrelated future actions unless the UI states that scope explicitly.
• Reject, cancel, timeout, and stop-run outcomes leave the run in a known terminal or fallback state with reason and recovery path.
• Edit-before-approve changes the payload, marks the gate revised, and re-runs validation before the edited action can resume.
• Delegate, reassign, escalate, and bypass actions preserve the original gate context and record actor, role, reason, timestamp, and version.
• Notifications and mobile approvals must deep-link to the canonical gate and refuse stale decisions.
• The audit trail records the gate reason, shown payload, approver eligibility, decision, comment, resume event, failure after approval, and override reason.

Implementation Checklist

• Model automation run ID, gate ID, step ID, proposed action, payload snapshot, payload hash, target object, trigger reason, risk level, evidence, confidence, source scope, approver rule, timeout, and downstream action separately.
• Define which actions require approval by policy, threshold, confidence, cost, data sensitivity, external side effect, deployment target, access scope, publication state, or customer impact.
• Render the paused step with prior completed steps, current gate, next step, action preview, payload diff, approver eligibility, timeout, and decision controls.
• Revalidate run state, payload hash, source freshness, model or workflow version, approver role, and policy before accepting approve, edit, reject, bypass, or mobile decisions.
• Add outcomes for approve and resume, edit and revalidate, reject with reason, cancel run, delegate, escalate, timeout, emergency stop, bypass with reason, failed resume, and rollback.
• Keep confidence, source grounding, citations, warnings, and audit history available as decision inputs without turning them into the gate itself.
• Log gate-visible payload, decision reason, actor, role, timestamp, version, notification source, stale-decision rejection, resume result, and downstream execution result.
• Test stale email approvals, self-review block, missing approver role, edited payload, timeout, delegate, bypass, failed resume, mobile decision, keyboard flow, screen-reader status updates, and high-zoom payload wrapping.

Common Generated-UI Mistakes

• Showing Approve without the exact action, payload, target, risk, or resume consequence.
• Using a post-action audit record as if it were a pre-action human gate.
• Letting stale notifications approve changed automation state.
• Allowing any viewer or the automation requester to approve when policy requires an eligible independent reviewer.
• Treating low confidence, source grounding, or warning text as a substitute for a human decision.
• Leaving rejected or timed-out gates suspended without cancel, fallback, edit, or retry state.
• Approving a whole run when the UI only described one step, or approving one step when future steps also need gates.
• Hiding the failure after approval, rollback, or downstream execution result from the approver.

Critique Questions

• What exact automation run, step, payload, target, and version is the human authorizing?
• Why did this gate trigger, and which policy, threshold, risk, or confidence condition requires human approval?
• Who is eligible to approve, who is blocked from self-review, and what happens if no one responds before timeout?
• What changes after approve, reject, edit, timeout, stop, delegate, escalate, or bypass?
• What revalidation prevents stale email, mobile, notification, or reopened-tab decisions from resuming unsafe automation?
• Does the audit trail prove what the human saw before approval and what actually executed after approval?