An approval boundary with a named owner, exact scope, inspectable evidence, and an honest failure path.
Put the decision where it still matters
A human approval step is useful only if it happens before the consequential action and the person can genuinely refuse. Showing a summary after a message has already been sent only notifies the owner. Approval must precede sending.
Name the decision owner. ‘A human will review it’ is incomplete when nobody knows who receives the request, what they are approving, or what happens if they do not respond. Silence should leave the action pending.
Show the object being approved
Approval should refer to a particular version of an output and a particular action. A person approving one draft has not approved a later rewrite, a different recipient, or a larger amount. Changes to material details should reopen review.
Present the proposed action, its supporting evidence, unresolved uncertainty, affected people, and recovery limits together. Avoid making the owner reconstruct the decision from a long transcript.
Action: Send the attached support reply Recipient: The requester on ticket EXAMPLE-04 Draft: Version 3, exact text attached Evidence: Current policy excerpt and its source Uncertainty: Exception request still unresolved Owner: Support lead If declined or unanswered: Retain as draft; send nothing
Make the boundary technical as well as verbal
A sentence in a prompt is a useful instruction, but it is not an access-control mechanism. In a real implementation, the preparation role should not possess a direct path to the consequential action. The application needs to verify the actual owner's authority and bind the approval to the action.
Avoid treating a model's report that ‘approval was granted’ as authentication. A document, tool response, or pasted message can contain untrusted claims. The trusted application must establish the approval through its own mechanism.
Plan for uncertainty after an action
Sometimes a request times out after the remote service accepted it. The outcome is unknown. The action may already have happened. Define how you will reconcile the state before trying again, especially when duplicate actions would matter.
Recovery also has limits. Deleting a public post does not erase every copy. Retracting an email cannot be assumed to remove it. Name what can be undone and what requires a person to handle the consequence.
Put the idea to work
Try it yourself
Choose an external action in your workflow. Write an approval packet for one exact version. Then change its recipient or content and explain why the original approval no longer covers it.
Inspect your result
- An identified owner can decline before the action.
- Approval covers an exact output and scope.
- Silence and missing evidence keep the action pending.
- The real implementation must enforce the boundary outside the prompt.
These are reflection prompts, not an assessment or certification. Use public or synthetic inputs.
Map roles in the Department Lab ↗Sources and context
A local design exercise for documenting roles and human authority; it does not implement production permissions.