Put human approval before an AI-triggered action

An AI-generated proposal can remain useful while waiting for a person to approve its exact effect. Store the proposal as data, then let application code move it through a documented lifecycle.

For a synthetic internal-task workflow, use states such as proposed, approved, executing and completed. Store who proposed it, who approved it and the revision that received approval. The execution worker reads an approved immutable revision rather than regenerating the task from the original prompt.

An approval screen should show the target and resulting action in terms the reviewer can assess. A vague "Approve AI result" button does not identify whether the action creates a draft, sends a message or updates a customer record.

Suggestion flowing through an approval record before execution.

Bind approval to what will execute

Give the proposal a revision ID or content hash. If a user edits the task after approval, require a new approval for the changed revision when the policy requires it. Otherwise an approved harmless draft can become a different action before the worker reads it.

Check authorization at approval time and again when executing. A reviewer can lose permission while a task waits in a queue. The worker also needs an operation identifier so a retry does not execute the same approved effect twice.

Database constraints can enforce local invariants, such as requiring an approval actor when the state is approved. Django's constraints reference and PostgreSQL's constraint documentation explain those mechanisms. A row constraint cannot by itself prove that the actor was authorized or that an external action ran exactly once.

Test conflicting transitions

Create a proposed task and attempt execution without approval. Then approve revision one, edit the content to revision two and try to execute using the old approval. Both attempts should fail under this workflow.

Try two workers claiming the same approved operation. Use an atomic state transition or another concurrency mechanism so only one owns execution. Test the case where an external effect succeeds but recording completion fails; a repeated request needs reconciliation or idempotency at the destination.

Record rejection and expiry too. A reviewer should be able to decline a proposal without leaving it available to an automatic executor. Approval can expire when source evidence becomes too old for the intended action.

This is a proposed application design, not a deployed authorization system. It does not claim that human review catches every mistake. Make the review material concise, keep effects bounded, and preserve an audit trail that ties each executed operation to the exact proposal and permission decision that allowed it.