NOD-005f — Handle a Node Execution Exception
Statement
The DIDO-TE SHALL handle each Test Execution Exception affecting the execution of a Node.
Derived From
-
[DTE5] DIDO-TE Requirements Register, source requirement identifier and obligation to be assigned
Rationale
A Test Execution Exception identifies a condition arising during Test Execution that differs from an applicable requirement, procedure, precondition, expected sequence, operating constraint, time constraint, or expected result.
A Node-related Test Execution Exception includes an unavailable or unresponsive Node, invalid Node state, rejected or misdirected Test Input, lost Node Binding, unavailable Test Resource, unexpected output, timing deviation, resource exhaustion, unauthorized interaction, configuration change, or interruption of Node execution.
Exception handling detects, classifies, assesses, contains, records, and dispositions the condition. The disposition may continue, retry, suspend, isolate, restart, recover, terminate, or invalidate affected activity according to an approved procedure and a decision by the applicable Authorizing Authority.
Uncontrolled exception handling may conceal a failure, alter the intended test conditions, contaminate other Nodes, or permit invalid Test Results to be treated as valid.
Applies To
Verification
Verification confirms that:
-
The DIDO-TE detects a Node execution condition that differs from the applicable criteria, procedure, sequence, constraint, or expected result.
-
Each Test Execution Exception has a unique identity.
-
Each Test Execution Exception identifies the affected Node, Test Execution, and Test Execution Exception Type.
-
Each exception identifies the expected condition and the observed condition.
-
The DIDO-TE identifies the time, sequence, source, scope, severity, and potential effect of the exception.
-
The DIDO-TE identifies affected Nodes, Node Bindings, Test Inputs, Test Resources, observations, Test Results, and Evidence.
-
The DIDO-TE uses identified and approved exception-handling criteria and procedures.
-
The DIDO-TE prevents an affected Node from continuing execution when continued activity presents an unacceptable risk.
-
The DIDO-TE contains or isolates the affected Node when required by the applicable procedure.
-
The DIDO-TE prevents the exception from affecting unrelated Nodes, Test Resources, or Test Executions.
-
The DIDO-TE retries an operation only when the applicable procedure permits the retry.
-
The DIDO-TE prevents unlimited, duplicate, or uncontrolled retries.
-
The DIDO-TE assigns each exception a disposition of continued execution, retry, suspension, isolation, restart, recovery, termination, invalidation, acceptance, or escalation.
-
Each disposition identifies its Authorizing Authority, rationale, scope, required actions, and applicable conditions.
-
The DIDO-TE records any approved continuation of execution under exceptional conditions.
-
The DIDO-TE verifies completion of each containment, corrective, recovery, termination, or escalation action.
-
The DIDO-TE determines the validity and required disposition of each affected Test Result.
-
The DIDO-TE determines whether the affected Test Execution continues, resumes, restarts, terminates, or requires another disposition.
-
The DIDO-TE assigns a distinguishable status to each detected, open, contained, accepted, resolved, or escalated exception.
-
The DIDO-TE prevents closure of an exception without an identified disposition and supporting Evidence.
-
The DIDO-TE records the exception identity, type, affected Node, Test Execution, expected condition, observed condition, detection time, scope, severity, findings, disposition, Authorizing Authority, actions, resulting Node state, and closure status.
-
The DIDO-TE maintains Traceability among the exception, Node Definition, Node Implementation, Node Configuration, Node Bindings, Test Definition, Test Inputs, Test Resources, observations, disposition, corrective actions, Test Results, and resulting Evidence.
-
An undetected, unhandled, unauthorized, unresolved, incorrectly dispositioned, or untraceable Test Execution Exception constitutes nonconformance with this requirement.
Verification includes:
-
Inspection of Test Execution Exception Types, criteria, and handling procedures
-
Introduction of an unavailable or unresponsive Node
-
Introduction of an invalid Node state
-
Introduction of a rejected, corrupted, or misdirected Test Input
-
Introduction of an unavailable Node Binding or Test Resource
-
Introduction of an unexpected output or timing deviation
-
Confirmation that each exception receives an identity, type, severity, scope, and disposition
-
Confirmation that the affected Node is contained or isolated when required
-
Confirmation that uncontrolled retries do not occur
-
Confirmation that the Authorizing Authority approves an exception disposition when required
-
Confirmation that affected Test Executions and Test Results receive an identified disposition
-
Inspection of exception records, corrective actions, closure records, Evidence, and Traceability
Referenced By
Related Architecture Sections
-
Add links to the architecture sections governing Test Execution Exceptions, exception classification, Node isolation, recovery, Test Result disposition, 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:03-node-requirements:nod-005-execute-a-node:nod-005f-handle-a-node-execution-exception#Statement&noheader&nofooter&noeditbtn}}
© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.