Use one fallback register
Choose who may start fallback work and who may stop it. Give each task a temporary reference and record what was actually completed, including external confirmations. Do not mark a task complete merely because someone attempted it. The following example is a synthetic booking outage.
| Reference | Requested slot | Completed action | Restored system match |
|---|---|---|---|
| FB-A | Room A, 14:00–15:00 | Authorised duty lead confirmed the fallback booking under the outage policy; synthetic confirmation FB-CONF-A | No system record yet; reconcile the confirmed reservation |
| FB-B | Room A, 14:00–15:00 | Request received only | Do not confirm; conflicts with FB-A |
| FB-C | Room B, 16:00–17:00 | Confirmation sent before outage | BK-608 found; do not create again |
Reconcile before releasing the backlog
- Stop new fallback entries
- Match each reference
- Resolve conflicts and unknown outcomes
- Release only verified pending work
Keep unresolved items assigned to a reviewer while other verified tasks resume.
Record the last fallback reference and the restart time. Verify one successfully reconciled task and one conflict in the restored system. If an external action such as a message or payment already happened, the recovery plan must account for it; restoring a database does not undo that action.