3.2.2. Human-in-the-Loop Patterns
💡 First Principle: Human-in-the-loop converts irreversibility into a checkpoint. The flow does everything automatable, then parks the decision with a named human — routing the request, waiting statefully, and branching on the verdict — so autonomy covers the reversible 95% and accountability covers the rest.
The canonical device is the approval: mid-flow, an approval action sends the decision package (what's being requested, by whom, with what details) to designated approvers, the flow suspends at that node, and approve/reject resumes it down the matching branch. Requests for additional information follow the same shape — pause, human input, resume with the answer in hand.
Design judgment is what gets examined: which steps deserve a checkpoint. Thresholds are the standard pattern — auto-approve under a limit, human above it — because they price the checkpoint where risk actually concentrates. And note the layering with 3.1.3: approvals in flows are the operational enforcement of the human-oversight layer your responsible-AI plan promised.
⚠️ Common Misconception: Human-in-the-loop means the flow simply pauses until someone resumes it. The pattern is structured — named approvers, a decision payload, stateful waiting, and explicit approve/reject branches. "Send an FYI email and continue" is notification, not HITL.
Reflection Question: A refund flow auto-approves under $100 and routes above it. What belongs in the approver's decision payload, and which branch — approve, reject, or timeout — is most often forgotten in design?
