Approval must happen before the consequential action
Human review is useful only when the reviewer can understand, reject and change the proposed action. A notification sent after an irreversible operation is not an approval step.
Classify actions by consequence and reversibility. Drafting a service summary is different from sending a customer commitment, changing access or deleting a record. Keep authority for the latter actions outside the model.
Make the approval specific
An approval screen should identify the object, proposed change, source information and expected consequence. The approved payload must be the one the server later executes. If the record changes in the meantime, require a fresh review rather than applying a stale decision.
| Control | Question it answers |
|---|---|
| Identity and role check | May this person approve this action? |
| Exact proposed payload | What will change? |
| Expiry and record version | Is the approval still current? |
| Single-use operation identifier | Has it already executed? |
| Audit event | Who approved and what actually happened? |
A generic “yes” in a long chat may be ambiguous. Bind it to a visible proposal or a clearly scoped action identifier. Do not infer approval from silence.
Design rejection and recovery
Allow the reviewer to edit, reject or request more information. Preserve the reasoning and corrections where appropriate. If execution fails after approval, show that state honestly and make retry behaviour safe.
Review fatigue matters: routing every trivial action to a person can cause habitual approval. Use deterministic rules for low-risk, well-defined work and reserve meaningful review for uncertainty or consequence. The boundary should be a documented business decision.
Test the race conditions
Try double approval, expired approval, changed records and a reviewer whose role was revoked. Confirm that server checks still protect the operation. A button disabled in the browser is not sufficient.
Use AI workflow design to make accountability visible, including the path when the reviewer rejects the suggestion.
A practical question
What if the record changes after approval?
Compare its version before execution. A changed record should require a fresh review of the exact proposed action. Reusing a stale approval can apply a decision to a different situation.