Design exceptions and safe retries
Course overview · 4 min reading + 12 min practice, estimated
Principles and method
List missing data, conflicting records, unavailable services and ambiguous outcomes. Decide which failures can be retried and which need a person. Use a stable operation identifier to prevent duplicate side effects. A timeout after a send may mean the message was sent but the response was lost; check state before repeating it. Route unresolved cases to an owned queue with enough context to continue manually. Set retry limits and a pause mechanism. A workflow that silently drops failures is incomplete even if the happy path looks impressive.
Worked example
The email service times out after accepting a pack. The workflow records the provider message identifier and reconciles delivery state instead of sending a second copy immediately.
Put it into practice
Create five test cases, including a duplicate trigger and an uncertain send result.
Use fictional information and keep your work in your own notes.
Compare your approach: self-review guidance
Specify expected state and visible operator action for each. The duplicate should not create another send. An uncertain result should remain visible until reconciled, not be marked successful by guesswork.
Sources and further reading
Original Academy teaching and fictional examples. These references provide context, not endorsement. Edition 2026.09; updated 2026-09-24.
- GOV.UK: Responsible AI in recruitment
UK guidance on procuring and deploying recruitment AI.
- NIST: AI Risk Management Framework
Voluntary framework for organising AI risks and controls.