Exception recovery when a workflow cannot finish

Distinguish missing information, contradictory sources, unavailable access, declined approval, and an interrupted operation. Each needs a different response. A missing source needs an owner; a denied approval needs a revised proposal. Repeating the same instruction is unlikely to fix either. Record the affected task and what the user expected to happen.

Before retrying, inspect the artifact or source system through an authorized route. Determine whether nothing happened, a draft was created, or part of the work completed. Keep the last approved version available. A message that says work is complete and an artifact that cannot be found represent an unresolved state, not a successful handoff.

Share the task, time, environment, visible error, expected result, and observed state with the assigned owner. Include only the information needed for diagnosis. For a source conflict, quote the relevant competing instructions and identify their owners. For an access problem, describe the required permission without sharing passwords or tokens in the report.

Agree whether to repair the draft, repeat an incomplete step, or abandon the attempt. Check for an existing result before creating another copy. If an external change may have occurred, the authorized owner should verify it before any retry. Record the recovery decision so a second operator does not repeat the same work independently.

For an intended Elvina pilot, rehearse at least one missing source, denied approval, and interrupted session with non-sensitive examples. Confirm that the user sees an honest state and can find the next step. This page describes the acceptance standard; actual retry, history, and recovery controls depend on the verified product environment.