# TD-T02: Recovery and resumption

Adrian Sutherland · Version 1.0 · Refreshed September 2026

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

Fictional cancellation service. Proposed design; checks are unrun.

## Impact and objectives

TD-R1: continuous case ownership and reliable operation receipts are essential. Business owner must agree acceptable interruption and recent recorded-work loss. No numeric objectives assumed.

## State and failure scope

C42's assignment and history, H7's accepted status, X7's retained result and the pending notification commit together. A restart must preserve these records. A backup taken before X7 may be internally consistent but omit a transfer already accepted.

## Copies and dependencies

Copy technology, retention and location open. Include keys, schema/runtime compatibility, identity, worker state and access to procedures. Provider redundancy alone does not prove recovery.

## Reconciliation

Pause acceptance and notification delivery; prevent old instances writing. Restore in controlled environment, establish recovery point and reconcile missing interval using available durable records and authorised business review. Missing X7 is not permission to repeat.

## Authority to resume

The technical operator restores and checks the platform. The service owner accepts the reconciled ownership and authorises resumption. The exact procedure and reconciliation sources remain open. Clients must resynchronise; restoring older data does not undo notifications already delivered or booking actions.

## Exercise and findings

TD-V1 includes restart after commit, pre-X7 restore, missing key, incompatible schema and replacement environment. All unrun. If required accepted records cannot survive the chosen failure scope, change the arrangement before adoption.