Price failed runs and corrections

A failed run can mean a repeated model call, reconciling an external action, recovering from partial state, notifying the user and some support work on top. I'd price that recovery path as part of the run.

Go stage by stage, list the ways each one can fail, and decide how you'll recover from each. A provider timeout before any action has happened might be safe to retry. A timeout after you've sent an instruction to another system can leave you not knowing whether it went through, which needs reconciling. A malformed structured response can be retried up to a limit, while a policy conflict probably needs a person.

For each recovery path, write down:

• how it's detected
• the retry rule and maximum attempts
• idempotency or duplicate protection
• what state is kept for recovery
• the person or service that owns the exception
• what the user is told
• the correction or reversal process
• what data is kept as evidence
• the expected handling cost

Put limits on retries. An unbounded loop can turn a provider problem into a big bill and a backlog at the same time. Use a circuit breaker or an operational pause once repeated failures cross a threshold you've agreed on. Base the threshold on the workflow's consequences and normal variation, and test it in a controlled environment.

Budget for wrong results that got accepted, too, alongside the technical failures. Fixing one might mean finding the affected records, restoring earlier values, contacting users and explaining the decision. Some actions can't be fully reversed at all, and those workflows need stronger approval controls and a remediation cost assumption before they launch.

I'd keep a small reserve for investigation and correction instead of pretending every cost is predictable. Set it from the risk review and adjust it as you learn more. Keep it as its own visible line, because a generic contingency figure won't tell you which failure mode is worth preventing.