The decision that matters
Bind approval to the specific action, recipient and parameters shown to the reviewer. If those values change, require a new decision. Show the source of important facts and make rejection a normal path. Keep approval separate from execution status: a permitted action may still fail because a provider is unavailable. Record both decisions so the operator can distinguish a rejected proposal from a failed delivery.
A practical scenario
For an email assistant, show the destination, subject and complete body before sending. Approval for one message should not authorize future messages to that address. If an operator edits the recipient after approval, the original approval is no longer sufficient. After sending, show the provider’s accepted or failed result without claiming the recipient has read it.
Before you ship
- Display the exact proposed change and affected recipient.
- Invalidate approval when material parameters change.
- Recheck current permissions at execution time.
A useful next step
Test a stale approval, a revoked user and an edited proposal. The system should refuse actions that no longer match the reviewed request. A useful approval interface reduces uncertainty for the reviewer instead of transferring an opaque model decision to a human click.
Primary reference & further reading
This guide combines general engineering recommendations with an illustrative scenario. Provider behavior can change; check current documentation before applying it. Read our editorial approach.