Check approval against the current input

In the document example, approval applies to a particular proposal. Keep the proposal version and the approval record together. Before resuming an external write, verify that the input still matches what was approved and that the approval remains valid under the workflow's rules.

A changed source document may need a new proposal and fresh review. It should not inherit approval simply because the case identifier stayed the same. Show the reviewer what changed and preserve the previous version so the decision can be understood later.

Access may also have changed while the case was waiting. Recheck the authority required for the operation at execution time. A recovery worker should use the intended service identity and account, not whichever administrator happens to be available to make the error disappear. If additional permission is required, record the request and follow the normal approval path.

Be careful about asking an agent to regenerate a missing intermediate result. Even with the same source material, a new model call can produce a different proposal. Save approved intermediate outputs so recovery can reuse the exact version. If the output was never persisted, mark that stage as incomplete and route the replacement through the required review.

A recovery screen can make these checks easier by placing the approved proposal beside the current source version and the intended destination. The operator needs to see the action they are about to authorise. A generic "retry failed job" button gives very little help when the run contains several different effects.

There is also a practical expiry question. A delayed request may no longer be wanted, even if the underlying API would accept it. Define who can cancel or reconfirm stale work. Keep that decision attached to the case so another worker cannot pick it up later as ordinary unfinished processing.