ENV-005j — Emulate Recovery Behaviour

Go to ENV-005 — Emulate Distributed Systems

Statement

The DIDO-TE SHALL emulate the recovery behaviour specified by the applicable Test Definition.

Derived From

, source requirement identifier and obligation to be assigned[DTE6] Structured Information Processing Reference Architecture (SIP-RA)[DTE7] Federated Data Interpretation Systems Reference Architecture (FDIS-RA)

Rationale

Recovery behaviour determines how a distributed system returns to an acceptable operational state following a failure, isolation event, resource constraint, membership change, topology change, or other disruption.

Relevant behaviour includes failure detection, restart, reconnection, failover, reconfiguration, state restoration, replay, resynchronisation, reconciliation, reintegration, leadership selection, quorum restoration, backlog processing, and return to service.

Recovery does not necessarily restore the exact pre-disruption state. The applicable Test Definition identifies the required recovery objective, acceptable resulting state, permitted data loss or duplication, timing criteria, consistency criteria, and completion conditions.

Controlled recovery emulation permits repeatable assessment of recovery sequences and their effects on participating Nodes, communication paths, state, data, and services.

Applies To

Verification

Verification confirms that:

The applicable Test Definition identifies each recovery behaviour subject to emulation.Each specified recovery behaviour has a unique identity.The Test Definition identifies the disruption, failure, or changed condition from which recovery begins.The Test Definition identifies each Node, Test Resource, communication path, service, state, or data set participating in the recovery.The Test Definition specifies the required pre-disruption state, disrupted state, and acceptable recovered state.The Test Definition specifies the recovery trigger, activation condition, sequence, scope, timing criteria, and completion criteria.The Test Definition specifies the applicable restart, reconnection, failover, reconfiguration, restoration, replay, resynchronisation, reconciliation, reintegration, and return-to-service behaviour.The Test Definition specifies the permitted loss, duplication, reordering, inconsistency, or unavailability during recovery.The Test Definition specifies the required post-recovery membership, topology, configuration, service availability, and data state.The DIDO-TE confirms the required disrupted state before activating the recovery behaviour.The DIDO-TE activates each recovery action under its specified conditions.The DIDO-TE performs recovery actions in the specified order.The DIDO-TE records the planned and actual start and completion times for each recovery action.The DIDO-TE observes participating Nodes, communication paths, services, state transitions, and data reconciliation throughout recovery.The DIDO-TE determines whether the recovery reaches the specified completion criteria.The DIDO-TE detects a recovery action that does not occur, occurs in the wrong order, exceeds its timing criteria, produces an unacceptable state, or remains incomplete.The DIDO-TE distinguishes specified recovery behaviour from an unintended environmental intervention.The DIDO-TE records recovery identities, triggers, actions, sequences, state transitions, timing measurements, reconciliation outcomes, resulting states, and detected deviations as Evidence.The DIDO-TE maintains Traceability among each recovery behaviour, originating disruption, affected Nodes and resources, Test Definition, Test Execution, Evidence, and Test Results.Missing, incomplete, incorrectly sequenced, untimely, uncontrolled, unobserved, unsupported, or untraceable mandatory recovery behaviour constitutes nonconformance with this requirement.Verification includes:

Inspection of the recovery behaviours specified by the Test DefinitionInspection of recovery identities, triggers, affected elements, actions, sequences, timing criteria, and completion criteriaComparison of the specified pre-disruption, disrupted, and recovered statesObservation of recovery following a Node failureObservation of recovery following a communication failure or network partitionObservation of recovery following a resource constraint or membership change, as applicableTesting of restart, reconnection, failover, state restoration, replay, resynchronisation, reconciliation, or reintegration, as applicableConfirmation that recovery actions occur in the specified orderMeasurement of recovery timing against the specified criteriaConfirmation that the recovered state satisfies the specified availability, consistency, membership, topology, configuration, and data criteriaConfirmation that the DIDO-TE detects an incomplete, incorrectly sequenced, untimely, or otherwise unacceptable recoveryInspection of recovery Evidence and Traceability recordsConfirmation that each mandatory recovery deviation produces a nonconformance result

Referenced By

Related Architecture Sections

Add links to the architecture sections governing failure detection, recovery control, restart, failover, state restoration, reconciliation, reintegration, service continuity, Evidence, and Traceability.

Delivery Phase

Assign the applicable delivery phase.

Requirement Status

Draft

Statement Reference

Use the following syntax to reference this requirement’s Statement section from another DokuWiki page:

{{section>dido:03-dido-te:99-annexes:annex-c-requirements:02-test-environment-requirements:env-005-emulate-distributed-systems:env-005j-emulate-recovery-behaviour#Statement&noheader&nofooter&noeditbtn}}

© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.