NOD-005f — Handle a Node Execution Exception

Go to NOD-005 — Execute a Node

Statement

The DIDO-TE SHALL handle each Test Execution Exception affecting the execution of a Node.

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

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 proceduresIntroduction of an unavailable or unresponsive NodeIntroduction of an invalid Node stateIntroduction of a rejected, corrupted, or misdirected Test InputIntroduction of an unavailable Node Binding or Test ResourceIntroduction of an unexpected output or timing deviationConfirmation that each exception receives an identity, type, severity, scope, and dispositionConfirmation that the affected Node is contained or isolated when requiredConfirmation that uncontrolled retries do not occurConfirmation that the Authorizing Authority approves an exception disposition when requiredConfirmation that affected Test Executions and Test Results receive an identified dispositionInspection 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

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.