# SI-T02: Failure and recovery

Adrian Sutherland · Version 1.0 · Refreshed September 2026

© 2005–2026 Adrian Sutherland.
Source page: https://architectureportal.org/assets/systems-integration

Fictional cancellation service. Proposed design; checks are unrun.

## Scope and sequence

SI-C01 / SI-D1. Receiver submits acceptance; case service checks and commits; client receives result; pending notification is delivered; consumers update. Booking confirmation is a separate operation.

## Known and unknown

Before acceptance, the existing assignment remains current. A timeout after send does not reveal whether the change committed. A failed notification does not undo an accepted assignment. A received handover event does not establish booking completion. Retained history and operation lookup distinguish these facts.

## Permitted recovery

Use X7 with unchanged inputs for an authorised repeat within the agreed retention period, or query its result. The service rejects reuse with changed inputs. After a stale-version rejection, review the current case and any new offer. After unknown or expired lookup, reconcile operation history and state before deciding another action. Never infer that the request failed from a missing response alone.

## Notification and consumer recovery

Retain the pending notification with the accepted update. Delivery retries independently. Consumers recognise event source and identity, check case versions and reconcile gaps. A current-state view may be repaired from the authoritative case; whether a specific notice was sent needs its own record. Set retry limits, failed-work handling and alert targets before delivery.

## People and service continuity

Assign named case-service support to resolve unknown operation results. The authoritative assignment remains the basis for case ownership. The duty coordinator investigates pending work and arranges cover through the accepted-transfer procedure. The service owner resolves authority or capacity gaps. A timed-out screen must not silently invent a new owner.

## Proposed checks

SI-V1 (all unrun):

| Scenario | Expected result | Actual result |
|---|---|---|
| Accepted update, lost response | Same X7 returns retained result; one assignment change | Not run |
| X7 reused with changed inputs | Reject; preserve original result | Not run |
| Two new accepts at version 12 | At most one applies | Not run |
| Restart after accepted update | Assignment, history, result and pending notification recover together | Not run |
| Duplicate or late event | Correct view retained; unresolved delivery recorded | Not run |
| Offline accept against newer case | Review required; accepted assignment preserved | Not run |
| Old receipt after later transfer | Historical receipt and current owner distinguished | Not run |
| Expired result lookup | Reconcile; no blind new operation | Not run |
| AI attempts unauthorised action | Reject; assignment preserved | Not run |
| Unknown booking result | Case unresolved; booking recovery invoked | Not run |

## Readiness and observations

Timing targets, operation retention and expiry, deployment, and named support remain open. Agree access and retention before using real case data. During a trial, record the time needed to establish outcomes, correct reports and resolve booking uncertainty, along with repeated work and support effort.