Check the approval still matches the input

In the document example, approval belongs to one particular proposal, so keep the proposal version and the approval record together. Before you resume an external write, check that the input still matches what was approved and that the approval is still valid under the workflow's rules.

If the source document has changed, it might need a new proposal and a fresh review. It shouldn't carry the old approval along just because the case identifier stayed the same. Show the reviewer what changed and keep the previous version, so anyone looking later can understand the decision.

Access might have changed while the case was waiting, too. Recheck the authority the operation needs at the time it runs. A recovery worker should use the intended service identity and account, and not whichever administrator happens to be around and wants the error gone. If it needs more permission, record the request and go through 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 give you a different proposal. Save approved intermediate outputs so recovery can reuse the exact version, and if an output was never saved, mark that stage as incomplete and send the replacement through the review it needs.

A recovery screen helps here if it puts the approved proposal next to the current source version and the intended destination, so the operator sees the action they're about to authorise. A generic "retry failed job" button doesn't tell them much when the run has several different effects.

There's also the question of expiry. A delayed request might not be wanted any more, even if the API would still accept it. Decide who can cancel or reconfirm stale work, and attach that decision to the case so another worker doesn't later treat it as ordinary unfinished processing.