| MO-001a — Infrastructure Environment Creation |
| Assess whether the current Crucible implementation creates an Infrastructure Environment from the selected Controlled Inputs. |
| Review and accept MO-001a as a proposed derived requirement created from the evaluation and decomposition of MO-001 in the Crucible System Requirements Specification, Version 1.1 Draft. |
| Identify the controlling source that defines which Controlled Inputs are selected for Infrastructure Environment creation. |
| Identify the criteria used to determine that the created Infrastructure Environment corresponds to the selected Controlled Inputs. |
| MO-001b — Deployment Duration |
| Measure the current Crucible implementation against the Deployment Duration established by the Acceptance Criteria. |
| Review and accept MO-001b as a proposed derived requirement created from the evaluation and decomposition of MO-001 in the Crucible System Requirements Specification, Version 1.1 Draft. |
| Define the Infrastructure Environment creation activity measured by the Deployment Duration. |
| Define the start condition and completion condition used to calculate the Deployment Duration. |
| Define the permitted Deployment Duration and identify the controlling Acceptance Criteria. |
| Identify any operational conditions, exclusions, or measurement tolerances that affect the Deployment Duration. |
| MO-001c — Reproducibility |
| Assess whether the current Crucible implementation reproduces Infrastructure Environments from the same Controlled Inputs in accordance with the defined equivalence criteria. |
| Review and accept MO-001c as a proposed derived requirement created from the evaluation and decomposition of MO-001 in the Crucible System Requirements Specification, Version 1.1 Draft. |
| Identify the controlling source that defines the equivalence criteria for reproduced Infrastructure Environments. |
| Identify the Infrastructure Environment characteristics that must remain equivalent across repeated creation. |
| Identify any permitted differences between the reference and reproduced Infrastructure Environments. |
| Determine whether reproducibility requires identical Controlled Input revisions or permits controlled substitution of equivalent inputs. |
| MO-001d — Security Baseline Conformance |
| Assess whether the current Crucible implementation creates Infrastructure Environments that conform to the selected Security Baseline. |
| Review and accept MO-001d as a proposed derived requirement created from the evaluation and decomposition of MO-001 in the Crucible System Requirements Specification, Version 1.1 Draft. |
| Identify the controlling source that selects the Security Baseline for each Infrastructure Environment. |
| Identify the security controls and conformance criteria that determine Security Baseline conformance. |
| Define how exceptions, deviations, waivers, and compensating controls affect Security Baseline conformance. |
| Define whether an Infrastructure Environment with unresolved security findings can satisfy this requirement. |
| MO-001e — Compliance Baseline Conformance |
| Assess whether the current Crucible implementation creates Infrastructure Environments that conform to the selected Compliance Baseline. |
| Review and accept MO-001e as a proposed derived requirement created from the evaluation and decomposition of MO-001 in the Crucible System Requirements Specification, Version 1.1 Draft. |
| Identify the controlling source that selects the Compliance Baseline for each Infrastructure Environment. |
| Identify the compliance requirements and conformance criteria that determine Compliance Baseline conformance. |
| Define how exceptions, deviations, waivers, and compensating measures affect Compliance Baseline conformance. |
| Define whether an Infrastructure Environment with unresolved compliance findings can satisfy this requirement. |
| MO-001 — Repeatable, Compliant, and Secure Infrastructure Environments |
| Review and approve the proposed decomposition of MO-001 into independently testable requirements. |
| Determine whether the child requirements under MO-001 collectively supersede MO-001. |
| If the child requirements are accepted as the complete replacement for MO-001, mark MO-001 as superseded and preserve this page as the parent Traceability record. |
| Define the duration, threshold, baseline, and measurement method represented by rapid. |
| Identify the Controlled Inputs and comparison criteria used to determine whether Infrastructure Environments are repeatable. |
| Identify the Compliance Baseline and acceptance criteria used to determine whether an Infrastructure Environment is compliant. |
| Identify the Security Baseline and required controls used to determine whether an Infrastructure Environment is secure. |
| Determine whether the child requirements under MO-001 provide complete coverage of the approved intent of MO-001. |
| MO-002a — Maximum Platform Deployment Duration |
| Measure the current Crucible implementation against the maximum Platform Deployment Duration established by the Acceptance Criteria. |
| Review and accept MO-002a as a proposed derived requirement created from the evaluation and decomposition of MO-002 in the Crucible System Requirements Specification, Version 1.1 Draft. |
| Identify the Platform Deployment activities included in the Deployment Duration measurement. |
| Define the starting event and completion event used to calculate Platform Deployment Duration. |
| Define the maximum permitted Platform Deployment Duration and identify the controlling Acceptance Criteria. |
| Define the measurement conditions, precision, exclusions, and tolerances used to evaluate Platform Deployment Duration. |
| Define how failed, incomplete, interrupted, and repeated Platform Deployments affect the measured Deployment Duration. |
| MO-002b — Platform Deployment Duration Reduction |
| Compare the current Crucible Platform Deployment Duration with the approved Deployment Baseline under equivalent measurement conditions. |
| Review and accept MO-002b as a proposed derived requirement created from the evaluation and decomposition of MO-002 in the Crucible System Requirements Specification, Version 1.1 Draft. |
| Identify the approved Deployment Baseline and its controlling source. |
| Define the baseline Platform Deployment process, scope, Controlled Inputs, starting event, completion event, included activities, and Deployment Duration. |
| Define the measurement conditions that must remain equivalent between the baseline and selected Platform Deployments. |
| Define the required amount of Platform Deployment Duration reduction. |
| Define how failed, incomplete, interrupted, and repeated Platform Deployments affect the baseline and measured results. |
| MO-002 — Reduced Platform Deployment Timelines |
| Review and approve the proposed decomposition of MO-002 into an absolute Platform Deployment Duration requirement and a relative Platform Deployment timeline-reduction requirement. |
| Determine whether automation is a required implementation constraint, an architectural decision, or explanatory source language that should not appear in the derived requirements. |
| Determine whether MO-002a and MO-002b collectively supersede MO-002. |
| If MO-002a and MO-002b are accepted as the complete replacement for MO-002, mark MO-002 as superseded and preserve this page as the parent Traceability record. |
| Identify the Platform Deployment activity measured by MO-002. |
| Define the start condition and completion condition used to calculate Platform Deployment Duration. |
| Define the maximum permitted Platform Deployment Duration represented by days or hours. |
| Identify the approved deployment-duration baseline represented by months. |
| Define the required reduction relative to the approved deployment-duration baseline. |
| Define how failed, interrupted, incomplete, or repeated Platform Deployments affect duration measurement. |
| Determine whether MO-002a and MO-002b provide complete coverage of the approved intent of MO-002. |
| MO-003a — Cross-Platform Deployment |
| Assess whether the current Crucible implementation deploys an Infrastructure Environment to two or more supported Deployment Platforms. |
| Review and accept MO-003a as a proposed derived requirement created from the evaluation and decomposition of MO-003 in the Crucible System Requirements Specification, Version 1.1 Draft. |
| Identify the Deployment Platforms that Crucible supports. |
| Define the criteria used to determine that a Deployment Platform is supported. |
| Confirm that deployment to two supported Deployment Platforms provides sufficient minimum evidence of cross-platform deployment. |
| Identify the deployment acceptance criteria for each supported Deployment Platform. |
| Identify the controlling source that approves the Provider Contract and Provider Implementation used for each supported Deployment Platform. |
| MO-003b — Provider-Independent Crucible Description |
| Assess whether deployments to the selected Deployment Platforms use the same identified version of the provider-independent Crucible Description. |
| Review and accept MO-003b as a proposed derived requirement created from the evaluation and decomposition of MO-003 in the Crucible System Requirements Specification, Version 1.1 Draft. |
| Define the provider-independent information that the Crucible Description must contain. |
| Define the provider-specific information that must remain separate from the Crucible Description. |
| Identify the controlling source that defines the boundary between provider-independent and provider-specific information. |
| Determine whether changing the selected Deployment Platform may require any controlled transformation of the Crucible Description without creating a new Crucible Description version. |
| Define the identifier and versioning rules used to determine that each deployment uses the same Crucible Description. |
| MO-003c — Provider-Independent Infrastructure Baseline |
| Assess whether deployments to the selected Deployment Platforms use the same identified version of the provider-independent Infrastructure Baseline. |
| Review and accept MO-003c as a proposed derived requirement created from the evaluation and decomposition of MO-003 in the Crucible System Requirements Specification, Version 1.1 Draft. |
| Define the provider-independent infrastructure requirements that the Infrastructure Baseline must contain. |
| Define the provider-specific information and implementation mechanisms that must remain separate from the Infrastructure Baseline. |
| Identify the controlling source that defines the boundary between provider-independent baseline requirements and provider-specific implementation details. |
| Determine whether changing the selected Deployment Platform may require any controlled transformation of the Infrastructure Baseline without creating a new Infrastructure Baseline version. |
| Define the identifier and versioning rules used to determine that each deployment uses the same Infrastructure Baseline. |
| MO-003d — Limitation of Provider-Specific Dependencies |
| Assess whether the current Crucible implementation confines proprietary Cloud Provider dependencies to the Provider Implementation for each target Deployment Platform. |
| Review and accept MO-003d as a proposed derived requirement created from the evaluation and decomposition of MO-003 in the Crucible System Requirements Specification, Version 1.1 Draft. |
| Define the architectural boundary of each Provider Implementation. |
| Identify the provider-independent Crucible components that must remain free of proprietary Cloud Provider dependencies. |
| Identify the proprietary interfaces, services, data formats, software development kits, and operational mechanisms permitted within each Provider Implementation. |
| Define whether proprietary Cloud Provider data formats may cross the Provider Implementation boundary and, if permitted, define the boundary conditions. |
| Identify the controlling source that associates each Provider Implementation with its target Deployment Platform. |
| MO-003 — Cloud-Agnostic Deployment |
| Review and approve the proposed decomposition of MO-003 into independently testable cloud-agnostic deployment requirements. |
| Determine whether MO-003a through MO-003d collectively supersede MO-003. |
| If MO-003a through MO-003d are accepted as the complete replacement for MO-003, mark MO-003 as superseded and preserve this page as the parent Traceability record. |
| Identify the target Deployment Platforms and the minimum number of platforms required to demonstrate Cloud Agnosticism. |
| Identify the deployable subject and the deployment outcome required on each target Deployment Platform. |
| Define the provider-independent deployment information that Crucible uses across target Deployment Platforms. |
| Determine whether the same Crucible Description must apply across all target Deployment Platforms. |
| Determine whether the same Infrastructure Baseline must apply across all target Deployment Platforms. |
| Identify the proprietary interfaces, services, data formats, software development kits, and operational mechanisms from which Crucible must limit dependence. |
| Define the permitted scope of provider-specific implementation behavior and variation. |
| Determine whether MO-003a through MO-003d provide complete coverage of the approved intent of MO-003. |
| MO-004a — Connected Environment Operations |
| Assess whether the current Crucible implementation executes each selected Operational Lifecycle activity in a Connected Environment. |
| Review and accept MO-004a as a proposed derived requirement created from the evaluation and decomposition of MO-004 in the Crucible System Requirements Specification, Version 1.1 Draft. |
| Identify the Operational Lifecycle activities that Crucible must execute within a Connected Environment. |
| Identify the controlling source that selects the Operational Lifecycle activities for a Connected Environment. |
| Define the starting condition, completion condition, required inputs, required outputs, and failure criteria for each selected Operational Lifecycle activity. |
| Identify the resources available within each Connected Environment and distinguish available resources from Authorized Resources. |
| MO-004b — Disconnected Environment Operations |
| Assess whether the current Crucible implementation executes each selected Operational Lifecycle activity in a Disconnected Environment. |
| Review and accept MO-004b as a proposed derived requirement created from the evaluation and decomposition of MO-004 in the Crucible System Requirements Specification, Version 1.1 Draft. |
| Identify the Operational Lifecycle activities that Crucible must execute within a Disconnected Environment. |
| Identify the controlling source that selects the Operational Lifecycle activities for a Disconnected Environment. |
| Define the starting condition, completion condition, required inputs, required outputs, and failure criteria for each selected Operational Lifecycle activity. |
| Identify the resources available within each Disconnected Environment and distinguish available resources from Authorized Resources. |
| Define the authorization, integrity, provenance, and admission checks required before imported resources become available within a Disconnected Environment. |
| MO-004c — Authorized Resource Use |
| Assess whether the current Crucible implementation accesses only Authorized Resources for the identified operational environment. |
| Review and accept MO-004c as a proposed derived requirement created from the evaluation and decomposition of MO-004 in the Crucible System Requirements Specification, Version 1.1 Draft. |
| Identify the authority that authorizes resources for each operational environment. |
| Define the authorization record required for each Authorized Resource. |
| Define how authorization scope, expiration, revocation, and intended use affect resource access. |
| Define the behavior required when Crucible encounters or attempts to access an unauthorized resource. |
| Define when an imported resource becomes authorized for use within an operational environment. |
| MO-004d — Disconnected Resource Availability |
| Assess whether the current Crucible implementation executes each selected Operational Lifecycle activity using only the required resources available within the Disconnected Environment boundary. |
| Review and accept MO-004d as a proposed derived requirement created from the evaluation and decomposition of MO-004 in the Crucible System Requirements Specification, Version 1.1 Draft. |
| Define the boundary of each Disconnected Environment. |
| Identify the controlling source that determines the resources required by each selected Operational Lifecycle activity. |
| Define when a resource is considered available within a Disconnected Environment. |
| Define the transfer, authorization, integrity, provenance, and admission checks required before an imported resource becomes available. |
| Define the behavior required when a resource needed by a selected Operational Lifecycle activity is unavailable within the environment boundary. |
| Define how attempted access to external resources is detected and recorded. |
| MO-004 — Connected and Disconnected Operations |
| Review and approve the proposed decomposition of MO-004 into independently testable Connected Environment, Disconnected Environment, resource-authorization, and resource-availability requirements. |
| Determine whether MO-004a through MO-004d collectively supersede MO-004. |
| If MO-004a through MO-004d are accepted as the complete replacement for MO-004, mark MO-004 as superseded and preserve this page as the parent Traceability record. |
| Identify the Operational Lifecycle activities that Crucible must perform within a Connected Environment. |
| Identify the Operational Lifecycle activities that Crucible must perform within a Disconnected Environment. |
| Define how Operational Lifecycle activities are selected for each environment. |
| Identify the Authorized Resources that Crucible may use within each environment. |
| Define the relationship between resource authorization and resource availability. |
| Define whether Crucible may depend on external network resources while operating within a Disconnected Environment. |
| Define when resources imported through an approved transfer process become available for use within a Disconnected Environment. |
| Determine whether MO-004a through MO-004d provide complete coverage of the approved intent of MO-004. |
| MO-005a — Infrastructure Baseline Artifact Management |
| Assess whether the current Crucible implementation manages each Infrastructure Baseline as an Artifact. |
| Review and accept MO-005a as a proposed derived requirement created from the evaluation and decomposition of MO-005 in the Crucible System Requirements Specification, Version 1.1 Draft. |
| Define the content that constitutes an Infrastructure Baseline Artifact. |
| Define the metadata required for each Infrastructure Baseline Artifact. |
| Identify the repository or storage mechanism used to manage Infrastructure Baseline Artifacts. |
| Define the storage, retrieval, and inspection behaviors required for Infrastructure Baseline Artifacts. |
| Define the criteria used to distinguish an Infrastructure Baseline Artifact from an Infrastructure Deployment created from that baseline. |
| MO-005b — Infrastructure Baseline Identification |
| Assess whether the current Crucible implementation assigns a unique Artifact identifier to each Infrastructure Baseline. |
| Review and accept MO-005b as a proposed derived requirement created from the evaluation and decomposition of MO-005 in the Crucible System Requirements Specification, Version 1.1 Draft. |
| Define the syntax of the Artifact identifier assigned to an Infrastructure Baseline. |
| Define the uniqueness scope for Infrastructure Baseline Artifact identifiers. |
| Identify the authority responsible for assigning Infrastructure Baseline Artifact identifiers. |
| Define the relationship between an Infrastructure Baseline Artifact identifier and an Infrastructure Baseline revision identifier. |
| Define the behavior required when Crucible detects an identifier collision. |
| Define the treatment of Artifact identifiers assigned to retired or withdrawn Infrastructure Baselines. |
| MO-005c — Infrastructure Baseline Revision Control |
| Assess whether the current Crucible implementation maintains each Infrastructure Baseline under Version Control. |
| Review and accept MO-005c as a proposed derived requirement created from the evaluation and decomposition of MO-005 in the Crucible System Requirements Specification, Version 1.1 Draft. |
| Define the Version Control mechanism used for Infrastructure Baselines. |
| Define the revision identifier assigned to each controlled Infrastructure Baseline revision. |
| Define the relationship recorded between successive Infrastructure Baseline revisions. |
| Define the change record required for each Infrastructure Baseline revision. |
| Define the approval-status information recorded for each Infrastructure Baseline revision. |
| Define the retention and retrieval requirements for prior Infrastructure Baseline revisions. |
| MO-005d — Approved Infrastructure Baseline Selection |
| Assess whether the current Crucible implementation selects an approved Infrastructure Baseline revision for each Infrastructure Deployment. |
| Review and accept MO-005d as a proposed derived requirement created from the evaluation and decomposition of MO-005 in the Crucible System Requirements Specification, Version 1.1 Draft. |
| Identify the authority that approves Infrastructure Baseline revisions. |
| Define the approval statuses that permit selection of an Infrastructure Baseline revision. |
| Define the Infrastructure Deployment context covered by an approval. |
| Define the selection criteria used when more than one approved Infrastructure Baseline revision is available. |
| Define the behavior required when no approved Infrastructure Baseline revision satisfies the deployment context. |
| Define whether and under what conditions a superseded Infrastructure Baseline revision may be selected. |
| MO-005e — Infrastructure Baseline Reuse |
| Assess whether the current Crucible implementation applies the same approved Infrastructure Baseline revision to two or more Infrastructure Deployments. |
| Review and accept MO-005e as a proposed derived requirement created from the evaluation and decomposition of MO-005 in the Crucible System Requirements Specification, Version 1.1 Draft. |
| Confirm that two Infrastructure Deployments provide the minimum sufficient demonstration of Infrastructure Baseline reuse. |
| Define the criteria used to determine that two Infrastructure Deployments apply the same Infrastructure Baseline revision. |
| Define the deployment-specific parameters that may differ without changing the reused Infrastructure Baseline revision. |
| Define the permitted differences among Infrastructure Environments produced from the same approved Infrastructure Baseline revision. |
| Define whether reuse across different Deployment Platforms or operational environments requires additional equivalence criteria. |
| MO-005f — Approved Infrastructure Baseline Preservation |
| Assess whether the current Crucible implementation preserves the content of each approved Infrastructure Baseline revision during reuse. |
| Review and accept MO-005f as a proposed derived requirement created from the evaluation and decomposition of MO-005 in the Crucible System Requirements Specification, Version 1.1 Draft. |
| Define the content included within an approved Infrastructure Baseline revision. |
| Define the integrity mechanism used to determine whether approved Infrastructure Baseline content has changed. |
| Define the deployment-specific parameters that remain external to the approved Infrastructure Baseline revision. |
| Define the behavior required when Crucible detects an attempted modification of approved Infrastructure Baseline content. |
| Define the process used to create a new revision when approved Infrastructure Baseline content requires a change. |
| Define the retention period and retrieval requirements for approved Infrastructure Baseline revisions. |
| MO-005g — Infrastructure Deployment Baseline Traceability |
| Assess whether the current Crucible implementation records the Artifact identifier and revision identifier of the Infrastructure Baseline used by each Infrastructure Deployment. |
| Review and accept MO-005g as a proposed derived requirement created from the evaluation and decomposition of MO-005 in the Crucible System Requirements Specification, Version 1.1 Draft. |
| Define the deployment record that preserves the relationship between an Infrastructure Deployment and the Infrastructure Baseline revision used. |
| Define when Crucible records the Infrastructure Baseline Artifact identifier and revision identifier. |
| Define the identifier-resolution mechanism used to resolve the recorded Artifact identifier and revision identifier. |
| Define the treatment of failed, incomplete, interrupted, and repeated Infrastructure Deployments. |
| Define the behavior required when the recorded Artifact identifier or revision identifier cannot be resolved. |
| Define the deployment-specific parameters that the deployment record must preserve separately from the Infrastructure Baseline reference. |
| MO-005 — Reusable and Version-Controlled Infrastructure Baselines |
| Review and approve the proposed decomposition of MO-005 into independently testable Infrastructure Baseline management, identification, revision-control, selection, reuse, preservation, and Traceability requirements. |
| Determine whether MO-005a through MO-005g collectively supersede MO-005. |
| If MO-005a through MO-005g are accepted as the complete replacement for MO-005, mark MO-005 as superseded and preserve this page as the parent Traceability record. |
| Define the Artifact-management requirements that apply to an Infrastructure Baseline. |
| Define the identifier assigned to each Infrastructure Baseline and the authority responsible for assigning it. |
| Define the revision identifier, revision sequence, and change-control rules for Infrastructure Baselines. |
| Define the approval authority and approval status required before an Infrastructure Baseline revision may be selected for Infrastructure Deployment. |
| Define the minimum number of Infrastructure Deployments required to demonstrate Infrastructure Baseline reuse. |
| Define whether reuse requires identical Controlled Inputs other than deployment-specific parameters. |
| Define the behavior required when a change to an approved Infrastructure Baseline is necessary. |
| Define the Traceability record that associates each Infrastructure Deployment with the Infrastructure Baseline identifier and revision used. |
| Determine whether MO-005a through MO-005g provide complete coverage of the approved intent of MO-005. |
| MO-006a — Operational Lifecycle Association |
| Assess whether the current Crucible implementation associates each Infrastructure Environment with an identified Operational Lifecycle revision. |
| Review and accept MO-006a as a proposed derived requirement created from the evaluation and decomposition of MO-006 in the Crucible System Requirements Specification, Version 1.1 Draft. |
| Identify the Operational Lifecycles that may govern an Infrastructure Environment. |
| Define the identifier and revision scheme used for Operational Lifecycles. |
| Identify the authority or process responsible for associating an Operational Lifecycle revision with an Infrastructure Environment. |
| Define when the Operational Lifecycle association becomes effective. |
| Define the behavior required when more than one Operational Lifecycle revision appears to govern the same Infrastructure Environment. |
| Define the behavior required when an associated Operational Lifecycle revision is superseded or withdrawn. |
| MO-006b — Infrastructure Lifecycle Initiation |
| Assess whether the current Crucible implementation designates the initial Infrastructure Deployment of an Infrastructure Environment as the first stage of its associated Operational Lifecycle revision. |
| Review and accept MO-006b as a proposed derived requirement created from the evaluation and decomposition of MO-006 in the Crucible System Requirements Specification, Version 1.1 Draft. |
| Define the criteria used to identify the initial Infrastructure Deployment of an Infrastructure Environment. |
| Define the event at which the initial Infrastructure Deployment first realizes the Infrastructure Environment. |
| Define the first stage of each Operational Lifecycle revision that may govern an Infrastructure Environment. |
| Identify the authority or process responsible for designating the initial Infrastructure Deployment as the first lifecycle stage. |
| Define whether pre-deployment planning, approval, and preparation belong to a separate lifecycle or process. |
| Define when a subsequent deployment creates a new Infrastructure Environment and initiates a new Operational Lifecycle. |
| MO-006c — Infrastructure Lifecycle State Recording |
| Assess whether the current Crucible implementation records the current Operational Lifecycle state of each Infrastructure Environment. |
| Review and accept MO-006c as a proposed derived requirement created from the evaluation and decomposition of MO-006 in the Crucible System Requirements Specification, Version 1.1 Draft. |
| Define the lifecycle states contained in each Operational Lifecycle revision. |
| Define the criteria used to assign each lifecycle state. |
| Define the source information Crucible uses to establish the current lifecycle state. |
| Define the behavior required when lifecycle records and observable Infrastructure Environment conditions conflict. |
| Define the state recorded after a failed, incomplete, interrupted, or rolled-back lifecycle transition. |
| Define when Crucible updates the current lifecycle-state record. |
| MO-006d — Infrastructure Lifecycle Transition Execution |
| Assess whether the current Crucible implementation executes each Operational Lifecycle transition allocated to Crucible when its transition conditions are satisfied. |
| Review and accept MO-006d as a proposed derived requirement created from the evaluation and decomposition of MO-006 in the Crucible System Requirements Specification, Version 1.1 Draft. |
| Define the Operational Lifecycle transitions allocated to Crucible. |
| Define the source state, target state, and transition conditions for each transition allocated to Crucible. |
| Define the completion and failure criteria for each transition allocated to Crucible. |
| Define the behavior required when one or more transition conditions are not satisfied. |
| Define the behavior required when transition execution fails, is interrupted, or remains incomplete. |
| Define the recovery or rollback behavior associated with each transition allocated to Crucible. |
| MO-006e — Infrastructure Environment Retirement |
| Assess whether the current Crucible implementation transitions an Infrastructure Environment to Retirement when its Retirement conditions are satisfied. |
| Review and accept MO-006e as a proposed derived requirement created from the evaluation and decomposition of MO-006 in the Crucible System Requirements Specification, Version 1.1 Draft. |
| Define the Retirement conditions for each Operational Lifecycle revision that permits Infrastructure Environment Retirement. |
| Identify the authority responsible for approving or authorizing Retirement. |
| Define the lifecycle state or states from which an Infrastructure Environment may transition to Retirement. |
| Define the completion and failure criteria for the Retirement transition. |
| Define the data, Artifact, resource, credential, service, and archival disposition activities required before Retirement. |
| Define the behavior required when one or more Retirement conditions are not satisfied. |
| Define the behavior required when the Retirement transition fails, is interrupted, or remains incomplete. |
| MO-006 — Infrastructure Lifecycle Management |
| Review and approve the proposed decomposition of MO-006 into independently testable lifecycle association, initiation, state-recording, transition-execution, and Retirement requirements. |
| Determine whether MO-006a through MO-006e collectively supersede MO-006. |
| If MO-006a through MO-006e are accepted as the complete replacement for MO-006, mark MO-006 as superseded and preserve this page as the parent Traceability record. |
| Identify the Operational Lifecycles that may be associated with an Infrastructure Environment. |
| Define how Crucible identifies the Operational Lifecycle revision associated with an Infrastructure Environment. |
| Define the lifecycle state assigned when an Infrastructure Environment is created through an Infrastructure Deployment. |
| Define the lifecycle states that Crucible records for an Infrastructure Environment. |
| Define the lifecycle transitions allocated to Crucible. |
| Define the conditions that permit each lifecycle transition. |
| Define the behavior required when a requested lifecycle transition is not permitted. |
| Define the conditions that permit Retirement of an Infrastructure Environment. |
| Define the records preserved for lifecycle state changes, transitions, and Retirement. |
| Determine whether MO-006a through MO-006e provide complete coverage of the approved intent of MO-006. |
| OR-001a — Developer Operations |
| Assess whether the current Crucible implementation performs each Crucible operation allocated to the Developer Role. |
| Review and accept OR-001a as a proposed derived requirement created from the evaluation and decomposition of OR-001 in the Crucible System Requirements Specification, Version 1.1 Draft. |
| Define Developer Role or reference an authoritative definition. Identify the essential characteristics of the role and distinguish the role from the DevSecOps Engineer Role, Platform Engineer Role, System Administrator Role, Security Engineer Role, and Compliance Officer Role. |
| Identify the controlling source that allocates Crucible operations to the Developer Role. |
| OR-001b — DevSecOps Engineer Operations |
| Assess whether the current Crucible implementation performs each Crucible operation allocated to the DevSecOps Engineer Role. |
| Review and accept OR-001b as a proposed derived requirement created from the evaluation and decomposition of OR-001 in the Crucible System Requirements Specification, Version 1.1 Draft. |
| Define DevSecOps Engineer Role or reference an authoritative definition. Identify the essential characteristics of the role and distinguish the role from the Developer Role, Platform Engineer Role, System Administrator Role, Security Engineer Role, and Compliance Officer Role. |
| Identify the controlling source that allocates Crucible operations to the DevSecOps Engineer Role. |
| OR-001c — Platform Engineer Operations |
| Assess whether the current Crucible implementation performs each Crucible operation allocated to the Platform Engineer Role. |
| Review and accept OR-001c as a proposed derived requirement created from the evaluation and decomposition of OR-001 in the Crucible System Requirements Specification, Version 1.1 Draft. |
| Define Platform Engineer Role or reference an authoritative definition. Identify the essential characteristics of the role and distinguish the role from the Developer Role, DevSecOps Engineer Role, System Administrator Role, Security Engineer Role, and Compliance Officer Role. |
| Identify the controlling source that allocates Crucible operations to the Platform Engineer Role. |
| OR-001d — System Administrator Operations |
| Assess whether the current Crucible implementation performs each Crucible operation allocated to the System Administrator Role. |
| Review and accept OR-001d as a proposed derived requirement created from the evaluation and decomposition of OR-001 in the Crucible System Requirements Specification, Version 1.1 Draft. |
| Define System Administrator Role or reference an authoritative definition. Identify the essential characteristics of the role and distinguish the role from the Developer Role, DevSecOps Engineer Role, Platform Engineer Role, Security Engineer Role, and Compliance Officer Role. |
| Identify the controlling source that allocates Crucible operations to the System Administrator Role. |
| OR-001e — Security Engineer Operations |
| Assess whether the current Crucible implementation performs each Crucible operation allocated to the Security Engineer Role. |
| Review and accept OR-001e as a proposed derived requirement created from the evaluation and decomposition of OR-001 in the Crucible System Requirements Specification, Version 1.1 Draft. |
| Define Security Engineer Role or reference an authoritative definition. Identify the essential characteristics of the role and distinguish the role from the Developer Role, DevSecOps Engineer Role, Platform Engineer Role, System Administrator Role, and Compliance Officer Role. |
| Identify the controlling source that allocates Crucible operations to the Security Engineer Role. |
| OR-001f — Compliance Officer Operations |
| Assess whether the current Crucible implementation performs each Crucible operation allocated to the Compliance Officer Role. |
| Review and accept OR-001f as a proposed derived requirement created from the evaluation and decomposition of OR-001 in the Crucible System Requirements Specification, Version 1.1 Draft. |
| Define Compliance Officer Role or reference an authoritative definition. Identify the essential characteristics of the role and distinguish the role from the Developer Role, DevSecOps Engineer Role, Platform Engineer Role, System Administrator Role, and Security Engineer Role. |
| Identify the controlling source that allocates Crucible operations to the Compliance Officer Role. |
| OR-001 — Operation by Identified User Categories |
| Review and approve the classification of Developer, DevSecOps Engineer, Platform Engineer, System Administrator, Security Engineer, and Compliance Officer as Crucible roles. |
| Determine whether OR-001a through OR-001f collectively supersede OR-001. |
| If OR-001a through OR-001f are accepted as the complete replacement for OR-001, mark OR-001 as superseded and preserve this page as the parent Traceability record. |
| Confirm that Developer, DevSecOps Engineer, Platform Engineer, System Administrator, Security Engineer, and Compliance Officer identify Crucible roles rather than job titles, organizational functions, user categories, or another kind of actor. |
| Define each proposed Crucible role or reference an authoritative definition. |
| Identify the controlling source that allocates Crucible operations to each proposed role. |
| Determine whether OR-001a through OR-001f provide complete coverage of the approved intent of OR-001. |
| OR-002a — Deployment to a Supported Target |
| Assess whether the current Crucible implementation deploys the Infrastructure Resources specified by a Deployment Description to each selected supported Deployment Target. |
| Review and approve OR-002a as a leaf requirement derived from OR-002. |
| Define how a Deployment Description identifies the Infrastructure Resources selected for deployment. |
| Define how a Deployment Target is selected for a Deployment. |
| Define how Crucible determines whether the selected Deployment Target is supported. |
| Define the behavior required when no Deployment Target is selected. |
| Define the behavior required when the selected Deployment Target is not supported. |
| Define the behavior required when an Infrastructure Resource is not supported by the selected Deployment Target. |
| Define the Deployment record required for a successful, unsuccessful, rejected, failed, or terminated Deployment. |
| OR-002b — Deployment Acceptance Assessment |
| Assess whether the current Crucible implementation evaluates each completed Deployment against the Acceptance Criteria defined for the selected Deployment Target. |
| Review and approve OR-002b as a leaf requirement derived from OR-002. |
| Define the Acceptance Criteria required for each supported Deployment Target. |
| Define when a Deployment is complete and ready for acceptance assessment. |
| Define how Crucible evaluates each Acceptance Criterion. |
| Define the behavior required when the selected Deployment Target does not identify Acceptance Criteria. |
| Define the behavior required when an Acceptance Criterion cannot be evaluated. |
| Define how the individual assessment results determine the overall Deployment acceptance result. |
| OR-002c — Deployment Acceptance Record |
| Assess whether the current Crucible implementation records the acceptance result of each completed Deployment assessed against the Acceptance Criteria defined for the selected Deployment Target. |
| Review and approve OR-002c as a leaf requirement derived from OR-002. |
| Define the permitted Deployment acceptance results. |
| Define the information required in a Deployment Acceptance Record. |
| Define how the Deployment Acceptance Record identifies the Acceptance Criteria used for the assessment. |
| Define how the Deployment Acceptance Record represents an Acceptance Criterion that could not be assessed. |
| Define the retention requirements for Deployment Acceptance Records. |
| Define the Evidence, Provenance, and Traceability required for each Deployment Acceptance Record. |
| OR-002 — Deployment Environments |
| Review and approve the decomposition of OR-002 into OR-002a through OR-002c. |
| Confirm that OR-002a through OR-002c preserve the complete approved intent of OR-002. |
| Determine whether OR-002a through OR-002c supersede OR-002. |
| Define how Crucible determines whether a selected Deployment Target is supported. |
| Define the Acceptance Criteria for each supported Deployment Target. |
| Define the possible Deployment acceptance results. |
| Determine whether deployment within an Air-Gapped Environment requires separate requirements under the Air-Gap Operations requirement family. |
| OR-003a — Classified Environment Operations |
| Assess whether the current Crucible implementation executes the selected Operational Lifecycle activities within an authorized Classified Environment. |
| Review and approve OR-003a as a leaf requirement derived from OR-003. |
| Define the Operational Lifecycle activities that Crucible must execute within each supported Classified Environment. |
| Identify the Security Classifications that each supported Classified Environment is authorized to handle. |
| Identify the Classification Authority governing each supported Classified Environment. |
| Define the Security Domain governing each supported Classified Environment. |
| Define the conditions for initiating, completing, rejecting, blocking, or terminating each selected Operational Lifecycle activity. |
| Define the records and Evidence required for each selected Operational Lifecycle activity. |
| Define the acceptance criteria for successful execution within each supported Classified Environment. |
| OR-003b — Unclassified Environment Operations |
| Assess whether the current Crucible implementation executes the selected Operational Lifecycle activities within an Unclassified Environment. |
| Review and approve OR-003b as a leaf requirement derived from OR-003. |
| Define the Operational Lifecycle activities that Crucible must execute within each supported Unclassified Environment. |
| Define the conditions for initiating, completing, rejecting, blocking, or terminating each selected Operational Lifecycle activity. |
| Define the records and Evidence required for each selected Operational Lifecycle activity. |
| Define the acceptance criteria for successful execution within each supported Unclassified Environment. |
| OR-003c — Security Domain Resource Enforcement |
| Assess whether the current Crucible implementation prevents each operation from accessing resources not authorized for its governing Security Domain. |
| Review and approve OR-003c as a leaf requirement derived from OR-003. |
| Identify the authority responsible for establishing each Security Domain used by Crucible. |
| Define how each Crucible operation identifies its governing Security Domain. |
| Define how each Security Domain identifies its authorized resources. |
| Define the behavior required when an operation does not identify a governing Security Domain. |
| Define the behavior required when a requested resource does not identify an associated Security Domain. |
| Define the record required when Crucible denies resource access because of a Security Domain restriction. |
| OR-003d — Security Domain Information Enforcement |
| Assess whether the current Crucible implementation prevents each operation from processing information not authorized within its governing Security Domain. |
| Review and approve OR-003d as a leaf requirement derived from OR-003. |
| Identify the authority responsible for establishing each Security Domain used by Crucible. |
| Define how each Crucible operation identifies its governing Security Domain. |
| Define how each Security Domain identifies the information authorized within the domain. |
| Define how Crucible determines the Security Domain associated with information. |
| Define the behavior required when an operation does not identify a governing Security Domain. |
| Define the behavior required when information does not identify an associated Security Domain. |
| Define the record required when Crucible denies information processing because of a Security Domain restriction. |
| OR-003e — Information Handling Rule Enforcement |
| Assess whether the current Crucible implementation prevents operations from handling information in a manner prohibited by the governing Information Handling Rules. |
| Review and approve OR-003e as a leaf requirement derived from OR-003. |
| Define how Crucible associates Information Handling Rules with each information object. |
| Define how Crucible resolves Information Handling Rules inherited from a Security Classification, Security Domain, source, owner, or governing authority. |
| Define how Crucible resolves conflicting Information Handling Rules. |
| Define the behavior required when an information object does not identify or resolve to governing Information Handling Rules. |
| Define the information-handling actions that Crucible can authorize or prohibit. |
| Define the record required when Crucible prevents an operation because of an Information Handling Rule. |
| OR-003f — Cross-Domain Transfer Control |
| Assess whether the current Crucible implementation transfers information between Security Domains only through an authorized Cross-Domain Transfer. |
| Review and approve OR-003f as a leaf requirement derived from OR-003. |
| Identify the authority responsible for authorizing each supported Cross-Domain Transfer. |
| Define how Crucible identifies the source Security Domain. |
| Define how Crucible identifies the destination Security Domain. |
| Define how Crucible identifies the information selected for transfer. |
| Define how Crucible determines whether a Cross-Domain Transfer is authorized. |
| Define the behavior required when the source and destination belong to the same Security Domain. |
| Define the behavior required when the source or destination Security Domain cannot be determined. |
| Define the record required for an authorized, denied, failed, or terminated Cross-Domain Transfer. |
| OR-003g — Security Domain Access Control |
| Assess whether the current Crucible implementation denies access requests not authorized for the requesting identity within the governing Security Domain. |
| Review and approve OR-003g as a leaf requirement derived from OR-003. |
| Define how Crucible identifies and authenticates the identity making an access request. |
| Define how each access request identifies its governing Security Domain. |
| Define how the governing Security Domain represents authorization for an identity and requested access. |
| Define the access actions subject to authorization. |
| Define the behavior required when the requesting identity cannot be authenticated. |
| Define the behavior required when the governing Security Domain cannot be determined. |
| Define the behavior required when an authorization decision cannot be obtained. |
| Define the record required when Crucible denies an access request. |
| OR-003 — Classified and Unclassified Environments |
| Review and approve the proposed decomposition of OR-003 into independently testable Classified Environment operations, Unclassified Environment operations, Security Domain enforcement, Information Handling Rule enforcement, Cross-Domain Transfer control, and Security Domain access-control requirements. |
| Determine whether OR-003a through OR-003f collectively preserve the complete approved intent of OR-003. |
| Determine whether OR-003a through OR-003f collectively supersede OR-003. |
| If the proposed child requirements are accepted as the complete replacement for OR-003, mark OR-003 as superseded and preserve this page as the parent Traceability record. |
| Define the Operational Lifecycle activities that Crucible must execute within Classified Environments. |
| Define the Operational Lifecycle activities that Crucible must execute within Unclassified Environments. |
| Identify the Security Classifications that each supported Classified Environment is authorized to handle. |
| Identify the Classification Authority governing each Security Classification used by Crucible. |
| Define the Security Domain boundaries governing each Classified Environment and Unclassified Environment. |
| Define the resources, information, operations, users, and processes authorized within each Security Domain. |
| Define the Information Handling Rules governing each Security Classification and handling designation. |
| Define how Crucible associates Information Handling Rules with information and information-bearing Artifacts. |
| Define the behavior required when information lacks a Security Classification or handling designation. |
| Define the Cross-Domain Transfer mechanisms authorized between supported Security Domains. |
| Define the authorization required for each Cross-Domain Transfer. |
| Define the validation, integrity, inspection, and destination-acceptance requirements for Cross-Domain Transfers. |
| Define the behavior required when information is not authorized for the destination Security Domain. |
| Define the identity, role, authorization, and need-to-know information used to control access within a Security Domain. |
| Define the behavior required when an automated process lacks authorization for a requested operation, resource, or information object. |
| Determine whether OR-003a through OR-003f provide complete coverage of the approved intent of OR-003. |
| OR-004a — Concurrent Environment Deployment |
| Assess whether the current Crucible implementation concurrently deploys two or more Infrastructure Environments. |
| Review and approve OR-004a as a leaf requirement derived from OR-004. |
| Define the point at which an Infrastructure Deployment begins for concurrency verification. |
| Define the point at which an Infrastructure Deployment ends for concurrency verification. |
| Determine whether a minimum overlap duration is required to demonstrate concurrent deployment. |
| Determine whether requirements elsewhere define a supported concurrency limit greater than two Infrastructure Environments. |
| Determine whether requirements elsewhere define behavior when Crucible reaches the supported concurrency limit. |
| OR-004b — Concurrent Environment Management |
| Assess whether the current Crucible implementation concurrently manages two or more Infrastructure Environments. |
| Review and approve OR-004b as a leaf requirement derived from OR-004. |
| Define the management operations included within concurrent environment management. |
| Define the point at which an environment management operation begins for concurrency verification. |
| Define the point at which an environment management operation ends for concurrency verification. |
| Determine whether a minimum overlap duration is required to demonstrate concurrent management. |
| Determine whether requirements elsewhere define a supported concurrency limit greater than two Infrastructure Environments. |
| Determine whether requirements elsewhere define behavior when Crucible reaches the supported concurrency limit. |
| OR-004 — Concurrent Environment Deployment and Management |
| Review and approve the decomposition of OR-004 into OR-004a and OR-004b. |
| Confirm that OR-004a and OR-004b preserve the complete approved intent of OR-004. |
| Determine whether OR-004a and OR-004b supersede OR-004. |
| Determine whether requirements elsewhere define a supported concurrency limit greater than two Infrastructure Environments. |
| Determine whether requirements elsewhere define behavior when Crucible reaches the supported concurrency limit. |
| OR-005 — Distributed Environment Management |
| Assess whether the current Crucible implementation performs Centralized Management of two or more Distributed Environments. |
| Review and approve the normalized OR-005 Statement. |
| Define Centralized Management in the shared Terms and Definitions corpus. |
| Define Distributed Environment in the shared Terms and Definitions corpus. |
| Determine which management operations demonstrate Centralized Management for verification of OR-005. |
| Determine whether the ConOps requires a particular Management Interface for Centralized Management. |
| FR-CFG-001 — Declarative Infrastructure Configuration |
| Assess whether the current Crucible implementation defines infrastructure through Declarative Configuration. |
| Review and approve FR-CFG-001 as a leaf requirement. |
| Determine the minimum information required for a Declarative Configuration to define infrastructure. |
| FR-CFG-003 — Reusable Infrastructure Blueprints |
| Review and approve FR-CFG-003 as a leaf requirement. |
| Determine whether reusable Infrastructure Blueprints permit controlled overrides and identify the rules governing those overrides. |
| FR-CFG-004 — Environment Inheritance |
| Review and approve FR-CFG-004 as a leaf requirement. |
| Determine whether Environment Inheritance requires a controlled definition in the shared Terms and Definitions corpus. |
| Determine whether separate requirements define overrides, inheritance depth, conflict resolution, or inheritance from multiple parent Infrastructure Configurations. |
| FR-CFG-005 — Configuration Version History |
| Review and approve FR-CFG-005 as a leaf requirement. |
| Determine whether Configuration Version History requires a controlled definition in the shared Terms and Definitions corpus. |
| Determine whether separate requirements define revision metadata, retention periods, deletion controls, comparison, or restoration. |
| FR-IMG-001 — Build Virtual Machine Images |
| Review and approve FR-IMG-001 as a leaf requirement. |
| Determine whether separate requirements define the minimum required contents of a Machine Image. |
| FR-IMG-002 — Build Container Images |
| Review and approve FR-IMG-002 as a leaf requirement. |
| Determine whether separate requirements define the minimum required contents of a Container Image. |
| FR-IMG-003 — Immutable Infrastructure Workflows |
| Review and approve FR-IMG-003 as a leaf requirement. |
| Determine whether Immutable Infrastructure Workflow requires a controlled definition in the shared Terms and Definitions corpus. |
| Determine whether separate requirements define replacement failure and recovery behavior. |
| FR-IMG-004 — Image Signing |
| Review and approve FR-IMG-004 as a leaf requirement. |
| Confirm that the Source Statement reproduces the exact wording of the controlling System Requirements Specification. |
| Determine whether separate requirements define the signing identity and signing-key requirements. |
| FR-IMG-005 — Image Verification |
| Review and approve FR-IMG-005 as a leaf requirement. |
| Determine whether separate requirements define the applicable trust conditions and trusted signing identities. |
| Determine whether separate requirements govern preservation of the Digital Signature Verification result. |
| FR-IMG-006 — Image Promotion Workflows |
| Review and approve FR-IMG-006 as a leaf requirement. |
| Determine whether separate requirements or policies define the applicable Image Promotion transition criteria. |
| Determine whether separate requirements govern preservation of the Image Promotion result. |
| FR-DEP-001 — Deploy Infrastructure Resources |
| Review and approve FR-DEP-001 as a leaf requirement. |
| Determine whether separate requirements identify the source that selects the Infrastructure Resources for a deployment. |
| Determine whether separate requirements identify the Deployment Target or Infrastructure Environment for the deployed Infrastructure Resources. |
| FR-DEP-002 — Deploy Virtual Machines |
| Review and approve FR-DEP-002 as a leaf requirement. |
| Determine whether separate requirements identify the Machine Image and configuration used for each Virtual Machine deployment. |
| Determine whether separate requirements identify the Deployment Target or Infrastructure Environment for each Virtual Machine deployment. |
| FR-DEP-003 — Deploy Kubernetes Clusters |
| Review and approve FR-DEP-003 as a leaf requirement. |
| Determine whether separate requirements identify the configuration used for each Kubernetes Cluster deployment. |
| Determine whether separate requirements identify the Deployment Target or Infrastructure Environment for each Kubernetes Cluster deployment. |
| FR-DEP-004 — Deploy Containerized Workloads |
| Review and approve FR-DEP-004 as a leaf requirement. |
| Determine whether separate requirements identify the Container Images and configuration used for each Containerized Workload deployment. |
| Determine whether separate requirements identify the Container Platform, Deployment Target, or Infrastructure Environment for each Containerized Workload deployment. |
| FR-DEP-005 — Deploy Platform Services |
| Review and approve FR-DEP-005 as a leaf requirement. |
| Determine whether separate requirements identify the configuration used for each Platform Service deployment. |
| Determine whether separate requirements identify the Deployment Target or Infrastructure Environment for each Platform Service deployment. |
| FR-DEP-006 — Deployment Rollback |
| Review and approve FR-DEP-006 as a leaf requirement. |
| Determine whether separate requirements define the conditions that initiate Deployment Rollback. |
| Determine whether separate requirements define the required result of Deployment Rollback. |
| FR-DEP-007 — Deployment Validation |
| Review and approve FR-DEP-007 as a leaf requirement. |
| Determine whether separate requirements identify the Acceptance Criteria used for Deployment Validation. |
| Determine whether separate requirements govern preservation of the Deployment Validation result. |
| FR-MC-001 — Cloud Provider Abstraction |
| Review and approve FR-MC-001 as a leaf requirement. |
| Determine whether Cloud Provider Abstraction requires a controlled definition in the shared Terms and Definitions corpus. |
| Determine whether separate requirements define the boundary between provider-independent deployment information and provider-specific parameters. |
| FR-MC-002 — Provider-Specific Extensions |
| Review and approve FR-MC-002 as a leaf requirement. |
| Determine whether separate requirements govern Provider Plugin discovery, installation, loading, and activation. |
| Determine whether separate requirements require Provider Plugins to conform to a Provider Contract. |
| FR-MC-003 — Deployment Portability Across Cloud Providers |
| Review and approve FR-MC-003 as a leaf requirement. |
| Determine whether Deployment Portability requires a controlled definition in the shared Terms and Definitions corpus. |
| Determine whether a separate verification profile should define the minimum number and types of Cloud Providers used to demonstrate deployment portability. |
| FR-MC-004 — Hybrid-Cloud Deployments |
| Review and approve FR-MC-004 as a leaf requirement. |
| Confirm that Hybrid-Cloud Deployment has a controlled definition in the shared Terms and Definitions corpus. |
| Determine whether separate requirements define cross-environment connectivity, security, identity federation, synchronization, and workload placement. |
| FR-MC-005 — Edge Deployments |
| Review and approve FR-MC-005 as a leaf requirement. |
| Determine whether Edge Deployment requires a controlled definition in the shared Terms and Definitions corpus. |
| Determine whether Edge Environment requires a controlled definition in the shared Terms and Definitions corpus. |
| Determine whether separate requirements define connectivity, synchronization, resource constraints, and network isolation for Edge Deployments. |
| FR-AG-001 — Disconnected Deployment Operations |
| Review and approve FR-AG-001 as a leaf requirement. |
| Determine whether separate requirements identify the resources that must be locally available for disconnected Deployment Operations. |
| Determine whether separate requirements define the external communication boundaries used for each Disconnected Environment. |
| FR-AG-002 — Artifact Export Packages |
| Review and approve FR-AG-002 as a leaf requirement. |
| Determine whether separate requirements define the minimum required contents and metadata of a Transfer Bundle. |
| Determine whether export and import must preserve one Transfer Bundle identity or may create distinct package records. |
| FR-AG-003 — Artifact Import Packages |
| Review and approve FR-AG-003 as a leaf requirement. |
| Determine whether separate requirements define the minimum validation required before a Transfer Bundle can be imported. |
| Determine whether separate requirements identify the destination environment or repository for imported Transfer Bundle contents. |
| Determine whether export and import must preserve one Transfer Bundle identity or may create distinct package records. |
| FR-AG-004 — Baseline Synchronization |
| Review and approve FR-AG-004 as a leaf requirement. |
| Determine whether Baseline Synchronization requires a controlled definition in the shared Terms and Definitions corpus. |
| Determine whether separate requirements define the Baseline properties that synchronization must preserve. |
| Determine whether separate requirements define synchronization direction, authorization, scheduling, and conflict handling. |
| FR-AG-005 — Deployment Traceability Across Disconnected Environments |
| Review and approve FR-AG-005 as a leaf requirement. |
| Determine whether separate requirements define the minimum traceability relationships required for disconnected Deployments. |
| Determine whether separate requirements define how traceability information is transferred between environments. |
| FR-COMP-001 — Compliance Baseline Definitions |
| Review and approve FR-COMP-001 as a leaf requirement. |
| Determine whether separate requirements govern Compliance Baseline identifiers, revisions, approval, and lifecycle state. |
| Determine whether separate requirements govern importing and maintaining externally defined Compliance Baselines. |
| Determine whether Compliance Baseline Definition requires a separate controlled term or whether Compliance Baseline is sufficient. |
| FR-COMP-002 — Compliance Scanning Tool Integration |
| Review and approve FR-COMP-002 as a leaf requirement. |
| Determine whether Compliance Scanning Tool requires a controlled definition in the shared Terms and Definitions corpus. |
| Determine whether separate requirements define the information exchanged with a Compliance Scanning Tool. |
| Determine whether separate requirements govern preservation and processing of Compliance Findings returned by a Compliance Scanning Tool. |
| FR-COMP-003 — Compliance Reporting |
| Review and approve FR-COMP-003 as a leaf requirement. |
| Determine whether Compliance Report requires a controlled definition in the shared Terms and Definitions corpus. |
| Determine whether separate requirements define the minimum required contents of a Compliance Report. |
| Determine whether separate requirements govern Compliance Report formats, retention, publication, and distribution. |
| FR-COMP-004 — Compliance Evidence Artifacts |
| Review and approve FR-COMP-004 as a leaf requirement. |
| Determine whether Compliance Evidence Artifact requires a controlled definition in the shared Terms and Definitions corpus. |
| Determine whether separate requirements define the minimum required contents and metadata of a Compliance Evidence Artifact. |
| Determine whether separate requirements govern signing, verification, retention, transfer, and publication of Compliance Evidence Artifacts. |
| FR-COMP-005 — DISA STIG Compliance Baselines |
| Review and approve FR-COMP-005 as a leaf requirement. |
| Determine whether separate requirements identify the DISA STIG products and revisions that Crucible must provide. |
| Determine whether separate requirements govern importing, updating, approving, and applying DISA STIG Compliance Baselines. |
| FR-COMP-006 — FedRAMP Baseline Definitions |
| Review and approve FR-COMP-006 as a leaf requirement. |
| Determine whether separate requirements identify the FedRAMP baselines and revisions that Crucible must define. |
| Determine whether separate requirements govern importing, updating, approving, maintaining, and applying FedRAMP Compliance Baselines. |
| FR-COMP-007 — Custom Compliance Frameworks |
| Review and approve FR-COMP-007 as a leaf requirement. |
| Determine whether Compliance Framework requires a controlled definition in the shared Terms and Definitions corpus. |
| Determine whether separate requirements govern importing, mapping, approving, publishing, and maintaining user-defined Compliance Frameworks. |
| Determine whether separate requirements govern deriving Compliance Baselines from user-defined Compliance Frameworks. |
| FR-COMP-008a — Compliance Scanning Abstraction |
| Review and approve FR-COMP-008a as a leaf requirement. |
| Determine whether Compliance Scanning Abstraction requires a controlled definition in the shared Terms and Definitions corpus. |
| Determine whether the architecture defines the operations and information exposed by the Compliance Scanning Abstraction. |
| FR-COMP-008b — Multiple Operating-System Support |
| Review and approve FR-COMP-008b as a leaf requirement. |
| Determine whether Operating System requires a controlled definition in the shared Terms and Definitions corpus. |
| Determine whether compliance criterion requires a controlled definition in the shared Terms and Definitions corpus. |
| Determine whether separate requirements identify the Operating Systems that Crucible must evaluate. |
| Determine whether separate requirements define the minimum compliance criteria for each Operating System. |
| FR-COMP-008 — Operating-System-Independent Compliance Scanning |
| Review and approve the decomposition of FR-COMP-008. |
| Create and approve FR-COMP-008a. |
| Create and approve FR-COMP-008b. |
| Determine whether Compliance Scanning Abstraction requires a controlled definition in the shared Terms and Definitions corpus. |
| Determine whether Operating System requires a controlled definition in the shared Terms and Definitions corpus. |
| Determine whether the minimum of two operating systems accurately expresses the intended portability threshold. |
| FR-COMP-009a — Security Control Traceability Matrix Evidence |
| Review and approve FR-COMP-009a as a leaf requirement. |
| Determine whether Security Control requires a controlled definition in the shared Terms and Definitions corpus. |
| Determine whether Security-Control Implementation Evidence requires a controlled definition in the shared Terms and Definitions corpus. |
| Determine whether a separate requirement defines the minimum identifiers and references required to associate the Evidence with an SCTM entry. |
| FR-COMP-009b — Risk Management Framework Evidence |
| Review and approve FR-COMP-009b as a leaf requirement. |
| Determine whether Security Control requires a controlled definition in the shared Terms and Definitions corpus. |
| Determine whether Security-Control Implementation Evidence requires a controlled definition in the shared Terms and Definitions corpus. |
| Determine whether separate requirements define the minimum identifiers, provenance, and references required for Evidence used in RMF activities. |
| Determine whether separate requirements identify the RMF activities for which Crucible must generate Evidence. |
| FR-COMP-009c — Authorization to Operate Evidence |
| Review and approve FR-COMP-009c as a leaf requirement. |
| Determine whether Security Control requires a controlled definition in the shared Terms and Definitions corpus. |
| Determine whether Security-Control Implementation Evidence requires a controlled definition in the shared Terms and Definitions corpus. |
| Determine whether separate requirements define the minimum identifiers, provenance, and references required for Evidence used in ATO activities. |
| Determine whether separate requirements identify the ATO activities for which Crucible must generate Evidence. |
| FR-COMP-009 — Security-Control Implementation Evidence |
| Review and approve the decomposition of FR-COMP-009. |
| Create and approve FR-COMP-009a. |
| Create and approve FR-COMP-009b. |
| Create and approve FR-COMP-009c. |
| Determine whether Security Control requires a controlled definition in the shared Terms and Definitions corpus. |
| Determine whether Security-Control Implementation Evidence requires a controlled definition in the shared Terms and Definitions corpus. |
| Determine whether separate requirements define the minimum content, identifiers, provenance, and references required for Security-Control Implementation Evidence. |
| Determine which Evidence characteristics are required for inclusion in an SCTM. |
| Determine which Evidence characteristics are required for use in RMF activities. |
| Determine which Evidence characteristics are required for use in ATO activities. |
| FR-COMP-010a — Compliance Finding Transfer Bundle Inclusion |
| Review and approve FR-COMP-010a as a leaf requirement. |
| Determine whether Compliance Finding requires a controlled definition in the shared Terms and Definitions corpus. |
| Determine whether separate requirements define the representation of Compliance Findings within a Transfer Bundle. |
| Determine whether separate requirements govern verification of Compliance Findings after Transfer Bundle import. |
| FR-COMP-010b — Compliance Finding Association Preservation |
| Review and approve FR-COMP-010b as a leaf requirement. |
| Confirm the controlled definition of Compliance Finding in the shared Terms and Definitions corpus. |
| Determine whether separate requirements define the identifier or reference mechanism used to preserve the association between a Compliance Finding and an Artifact. |
| Determine whether separate requirements govern verification of the preserved association after Transfer Bundle import. |
| FR-COMP-010 — Transferable Compliance Findings |
| Review and approve the decomposition of FR-COMP-010. |
| Create and approve FR-COMP-010a. |
| Create and approve FR-COMP-010b. |
| Determine whether Compliance Finding requires a controlled definition in the shared Terms and Definitions corpus. |
| Confirm that Transfer Bundle is the controlling term for the source phrase transferable dependency/evidence bundle. |
| Determine whether the source term disconnected enclave means Disconnected Environment or requires a distinct Enclave definition. |
| Determine whether separate requirements govern verification of Compliance Findings and their Artifact associations after Transfer Bundle import. |
| FR-DSO-001 — Git-Based Workflow Integration |
| Review and approve FR-DSO-001 as a leaf requirement. |
| Determine whether separate requirements identify the Git repository operations that Crucible must perform. |
| Determine whether separate requirements govern repository authentication, authorization, and credential management. |
| Determine whether separate requirements identify the repository state used by each Crucible operation. |
| FR-DSO-002 — GitOps Workflow Integration |
| Review and approve FR-DSO-002 as a leaf requirement. |
| Determine whether separate requirements identify the GitOps operations that Crucible must perform. |
| Determine whether separate requirements govern desired-state retrieval, drift detection, reconciliation, and reconciliation-status reporting. |
| Determine whether separate requirements govern repository authentication, authorization, and credential management for GitOps Workflows. |
| FR-DSO-003 — CI/CD Pipeline Integration |
| Review and approve FR-DSO-003 as a leaf requirement. |
| Determine whether separate requirements identify the CI/CD Pipeline operations that Crucible must support. |
| Determine whether separate requirements govern pipeline authentication, authorization, and credential management. |
| Determine whether separate requirements define the status and result information exchanged between Crucible and a CI/CD Pipeline. |
| FR-DSO-004 — Automated Build Execution |
| Review and approve FR-DSO-004 as a leaf requirement. |
| Determine whether Build Operation requires a controlled definition in the shared Terms and Definitions corpus. |
| Determine whether separate requirements define the required build inputs, outputs, metadata, and status information. |
| Determine whether separate requirements govern build isolation, dependency resolution, repeatability, signing, and publication. |
| FR-DSO-005 — Automated Deployment Execution |
| Review and approve FR-DSO-005 as a leaf requirement. |
| Determine whether separate requirements define the required Deployment Operation inputs, outputs, metadata, and status information. |
| Determine whether separate requirements govern deployment approval, rollback criteria, validation, and post-deployment monitoring. |
| Determine whether separate requirements identify the Deployment Targets for which Crucible must execute automated Deployment Operations. |
| FR-DSO-006 — Automated Validation Execution |
| Review and approve FR-DSO-006 as a leaf requirement. |
| Determine whether separate requirements define the required Validation Operation inputs, outputs, metadata, and status information. |
| Determine whether separate requirements identify the subjects and Acceptance Criteria for which Crucible must execute automated Validation Operations. |
| Determine whether separate requirements govern validation failure handling, remediation, approval, and result retention. |
| C.3.8 DevSecOps Integration |
| Review and approve the DevSecOps Integration requirement set. |
| Review and approve FR-DSO-001 through FR-DSO-006 as leaf requirements. |
| Confirm that the requirement set distinguishes Git-based workflow integration, GitOps workflow integration, and CI/CD Pipeline integration without overlapping normative behavior. |
| Confirm that the automated build, deployment, and validation requirements identify independently verifiable operations. |
| Confirm that controlled Terms and Definitions entries exist for all architectural concepts used by the leaf requirements. |
| FR-BAS-001 — Consume Baseline Repositories from a Workspace |
| Review and approve FR-BAS-001 as a leaf requirement. |
| Determine whether separate requirements identify the Baseline Repository revisions that Crucible must consume. |
| Determine whether separate requirements govern repository authentication, authorization, and credential management. |
| Determine whether separate requirements define the Workspace structure used to locate and distinguish Baseline Repositories. |
| FR-BAS-002 — Compose Selected Baselines |
| Review and approve FR-BAS-002 as a leaf requirement. |
| Determine whether Application Source requires a controlled definition in the shared Terms and Definitions corpus. |
| Determine whether separate requirements define composition ordering, conflict resolution, and dependency resolution. |
| Determine whether separate requirements identify the required output and metadata of a Baseline Composition operation. |
| FR-BAS-003 — Process Predeployment and Postdeployment Steps |
| Review and approve FR-BAS-003 as a leaf requirement. |
| Determine whether Predeployment Step and Postdeployment Step require controlled definitions in the shared Terms and Definitions corpus. |
| Determine whether separate requirements define the representation, ordering, inputs, outputs, and status of deployment-related steps. |
| Determine whether separate requirements govern step failure handling, retry behavior, rollback, and continuation. |
| FR-BAS-004 — Perform Noninteractive Workspace Execution |
| Review and approve FR-BAS-004 as a leaf requirement. |
| Determine whether separate requirements define the input mechanisms available to noninteractive Workspace operations. |
| Determine whether separate requirements govern credential delivery and secret handling during noninteractive execution. |
| Determine whether separate requirements define timeout, retry, cancellation, and failure-reporting behavior for noninteractive Workspace operations. |
| C.3.9 Baseline Composition and Workspace |
| Review and approve the Baseline Composition and Workspace requirement set. |
| Review and approve FR-BAS-001 through FR-BAS-004 as leaf requirements. |
| Confirm that FR-BAS-001 distinguishes consumption of Baseline Repositories from Baseline Selection and Baseline Composition. |
| Confirm that FR-BAS-003 separates predeployment and postdeployment behavior when those activities require independent verification. |
| Confirm that FR-BAS-004 defines observable noninteractive behavior without adding requirements for a particular automation platform. |
| FR-DEPC-001 — Capture Build Dependencies |
| Review and approve FR-DEPC-001 as a leaf requirement. |
| Determine whether separate requirements define the dependency information that Crucible must record during Dependency Capture. |
| Determine whether separate requirements govern dependency identity, revision, source, provenance, and integrity information. |
| Determine whether separate requirements define handling of unavailable or unresolved Build Dependencies. |
| FR-DEPC-002 — Preserve Dependencies in a Dependency Store |
| Review and approve FR-DEPC-002 as a leaf requirement. |
| Determine whether separate requirements define the identity, revision, source, provenance, and integrity information preserved with each Build Dependency. |
| Determine whether separate requirements govern Dependency Store retention, replication, deduplication, and recovery. |
| Determine whether separate requirements define how Crucible retrieves preserved Build Dependencies from a Dependency Store. |
| FR-DEPC-003 — Produce a Transfer Bundle |
| Review and approve FR-DEPC-003 as a leaf requirement. |
| Determine whether separate requirements define the required contents and metadata of a Transfer Bundle. |
| Determine whether separate requirements govern Transfer Bundle integrity, signing, encryption, compression, and verification. |
| Determine whether separate requirements identify which captured Build Dependencies must be included in a Transfer Bundle. |
| FR-DEPC-004 — Populate Offline Repositories |
| Review and approve FR-DEPC-004 as a leaf requirement. |
| Determine whether separate requirements identify the Offline Repository types that Crucible must populate. |
| Determine whether separate requirements define the metadata and dependency information preserved during Offline Repository population. |
| Determine whether separate requirements govern Transfer Bundle validation, integrity verification, and authorization before Offline Repository population. |
| FR-DEPC-005 — Dependency Store Implementation Independence |
| Review and approve FR-DEPC-005 as a leaf requirement. |
| Determine whether the architecture explicitly identifies the operations and information defined by the Dependency Capture Contract. |
| Determine whether separate requirements define conformance criteria for alternative Dependency Store implementations. |
| Determine whether separate requirements govern migration of preserved dependencies between Dependency Store implementations. |
| C.3.10 Dependency Capture and Offline Transfer |
| Review and approve the Dependency Capture and Offline Transfer requirement set. |
| Review and approve FR-DEPC-001 through FR-DEPC-005 as leaf requirements. |
| Confirm that the requirement set distinguishes Dependency Capture, Dependency Store management, Transfer Bundle creation, Offline Repository population, and Dependency Store implementation independence without overlapping normative behavior. |
| Confirm that requirements governing Offline Transfer identify the source environment, destination environment, Transfer Boundary, and required transfer result when the controlling source establishes that information. |
| Confirm that requirements governing transfer across a Transfer Boundary identify the applicable Transfer Authorization and Transfer Bundle Integrity obligations. |
| FR-UI-001 — Shared Interface Operations |
| Review and approve FR-UI-001 as a leaf requirement. |
| Confirm whether the controlling source requires complete operational parity or permits interface-specific operations. |
| Confirm whether the controlling source requires a shared internal engine in addition to shared externally observable operations. |
| Determine whether security, administrative, or diagnostic operations can be restricted to one interface. |
| FR-UI-002 — Command-Line Interface |
| Review and approve FR-UI-002 as a leaf requirement. |
| Confirm which Crucible operations the Command-Line Interface must expose. |
| Determine whether separate requirements define command syntax, input conventions, output formats, exit status conventions, and error reporting. |
| Confirm whether the controlling source requires the Command-Line Interface to remain the primary Crucible interface. |
| FR-UI-003 — Web-Based User Interface |
| Review and approve FR-UI-003 as a leaf requirement. |
| Confirm which Crucible operations the Web-Based User Interface must expose. |
| Confirm whether the Web-Based User Interface must support management of multiple Infrastructure Environments as an explicit requirement. |
| Determine whether separate requirements define browser support, accessibility, authentication, session management, status presentation, error reporting, and result presentation. |
| C.3.11 Crucible Interfaces |
| Review and approve the decomposition of the Crucible Interfaces requirements into shared interface operations, a Command-Line Interface, and a Web-Based User Interface. |
| Confirm whether the Command-Line Interface remains the primary interface or whether the architecture treats the Command-Line Interface and Web-Based User Interface as equivalent access paths. |
| Confirm whether the controlling source requires behavioral parity between the Command-Line Interface and Web-Based User Interface or requires both interfaces to use the same underlying engine implementation. |
| Determine whether the operations exposed through both interfaces require a separately defined controlled term. |
| [DTE5] DIDO-TE Requirements Register |
| Record the authoritative filename. |
| Record the authoritative version. |
| Record the authoritative document date. |
| Record the authoritative file format. |
| MO-002a — Reproducible Test Environments |
| TBD |
| Assess the current DIDO-TE implementation against the Test Environment Reproducibility conditions established by the Acceptance Criteria. |
| Review and approve MO-002a as a proposed derived requirement created from the decomposition of MO-002. |
| Confirm the Original Requirement identifiers in the draft DIDO-TE Requirements Register that provide the source for MO-002a. |
| Define the Test Environment characteristics subject to reproduction. |
| Define which Test Environment characteristics require exact equivalence. |
| Define which Test Environment characteristics permit variation. |
| Define the permitted variation for each applicable Test Environment characteristic. |
| Define the method used to compare the selected and recreated Test Environments. |
| Define the equivalence criteria for substituted Resources. |
| Define the treatment of unavailable Resources and Dependencies. |
| Define the treatment of failed, incomplete, and interrupted Test Environment recreation attempts. |
| Define the Evidence required to demonstrate Test Environment Reproducibility. |
| Define the Test Environment Reproducibility requirements for Connected, Disconnected, and Air-Gapped Environments. |
| MO-002b — Reproducible Test Execution |
| TBD |
| Assess the current DIDO-TE implementation against the Test Execution Reproducibility obligation established by MO-002b. |
| Review and accept MO-002b as a proposed derived requirement created from the evaluation and decomposition of MO-002. |
| Confirm whether repeatability or reproducibility identifies the approved quality required for repeated Test Execution. |
| Define the Test Execution characteristics subject to comparison. |
| Define the permitted variation for each compared Test Execution characteristic. |
| Define the comparison methods, measurement conditions, precision, exclusions, and tolerances used to determine Test Execution Reproducibility. |
| Define the Test Definition, Test Sequence, Sequence Steps, Test Argument Values, Starting Conditions, Timing Conditions, Execution Paths, and Timeouts that must remain controlled during repeated Test Execution. |
| Define which Test Executable, Executable Artifact, Dependency, and Execution Facility Versions must remain unchanged during repeated Test Execution. |
| Define the permitted differences among Operational Resources used for repeated Test Execution. |
| Define how DIDO-TE identifies and evaluates nondeterministic behavior. |
| Define how failed, incomplete, interrupted, timed-out, canceled, and repeated Test Runs affect the determination of Test Execution Reproducibility. |
| Define the Evidence required to demonstrate Test Execution Reproducibility. |
| MO-002 — Reproducible Test Environments and Test Execution |
| Identify the authoritative source, original requirement identifier, and controlling citation for this Original Requirement. |
| Review and approve the decomposition of MO-002 into MO-002a and MO-002b. |
| Confirm whether Repeatability, Reproducibility, or separate requirements for both qualities preserve the approved intent of the Original Requirement. |
| Determine whether MO-002a and MO-002b collectively supersede MO-002. |
| If MO-002a and MO-002b are accepted as the complete replacement for MO-002, mark MO-002 as superseded and preserve this page as the parent [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceability]] record. |
| Identify the authoritative source, original requirement identifier, and controlling citation for the Original Requirement. |
| Confirm the relationship between Repeatability and [[dido:99_annexes:annex-b-terms-and-definitions:r:reproducibility|Reproducibility]] within DIDO-TE. |
| Determine whether Repeatability requires a separate shared Terms and Definitions entry. |
| Define the controlled and variable characteristics of a reproducible [[dido:99_annexes:annex-b-terms-and-definitions:t:test_environment|Test Environment]]. |
| Define the [[dido:99_annexes:annex-b-terms-and-definitions:c:configuration|Configuration]], [[dido:99_annexes:annex-b-terms-and-definitions:v:version|Versions]], [[dido:99_annexes:annex-b-terms-and-definitions:d:dependency|Dependencies]], [[dido:99_annexes:annex-b-terms-and-definitions:o:operational_resource|Operational Resources]], and [[dido:99_annexes:annex-b-terms-and-definitions:d:deployment_target|Deployment Targets]] that DIDO-TE must preserve or recreate. |
| Define the [[dido:99_annexes:annex-b-terms-and-definitions:t:test_definition|Test Definitions]], [[dido:99_annexes:annex-b-terms-and-definitions:t:test_sequence|Test Sequences]], [[dido:99_annexes:annex-b-terms-and-definitions:s:sequence_step|Sequence Steps]], [[dido:99_annexes:annex-b-terms-and-definitions:t:test_argument_value|Test Argument Values]], [[dido:99_annexes:annex-b-terms-and-definitions:s:starting_condition|Starting Conditions]], [[dido:99_annexes:annex-b-terms-and-definitions:t:timing_condition|Timing Conditions]], and [[dido:99_annexes:annex-b-terms-and-definitions:e:execution_path|Execution Paths]] that DIDO-TE must preserve for reproducible Test Execution. |
| Define whether Reproducibility requires exact equality or permits bounded variation. |
| Define the permitted variation for Test Environment recreation. |
| Define the permitted variation for repeated Test Execution and resulting [[dido:99_annexes:annex-b-terms-and-definitions:t:test_result|Test Results]]. |
| Define the comparison methods, tolerances, precision, and treatment of nondeterministic behavior. |
| Define how failed, incomplete, interrupted, timed-out, canceled, and repeated [[dido:99_annexes:annex-b-terms-and-definitions:t:test_run|Test Runs]] affect the determination of Reproducibility. |
| Define the [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]], [[dido:99_annexes:annex-b-terms-and-definitions:p:provenance|Provenance]], and Traceability required to demonstrate Test Environment and Test Execution Reproducibility. |
| Determine whether MO-002a and MO-002b provide complete coverage of the approved intent of MO-002. |
| MO-004a — DIDO Baseline Comparison |
| TBD |
| Assess the current DIDO-TE implementation against the DIDO Baseline comparison obligation established by MO-004a. |
| Review and accept MO-004a as a proposed derived requirement created from the evaluation and decomposition of MO-004. |
| Determine whether DIDO Baseline requires a separate shared Terms and Definitions entry or identifies a DIDO-specific application of Baseline. |
| Determine whether Baseline Test Result requires a separate shared Terms and Definitions entry. |
| Define how DIDO-TE identifies the controlling DIDO Baseline and DIDO Baseline Version. |
| Define how DIDO-TE establishes correspondence between a selected Test Result and a Test Result in the controlling DIDO Baseline. |
| Define the Test Result characteristics subject to comparison. |
| Define the supported quantitative, qualitative, structural, behavioral, temporal, semantic, binary, and statistical comparison methods. |
| Define the measurement conditions, units, precision, exclusions, and tolerances used for each comparison method. |
| Define the classifications assigned to equality, difference, improvement, degradation, and inconclusive comparison outcomes. |
| Define the treatment of missing, invalid, incompatible, or unavailable Test Results. |
| Define the treatment of nondeterministic Test Results. |
| Define the treatment of Test Results produced by Incomplete Test Runs for each applicable Test Run Termination Reason. |
| Define the Evidence DIDO-TE must preserve for each comparison outcome. |
| MO-004b — Validation Decision Based on DIDO Baseline Comparison |
| TBD |
| Assess the current DIDO-TE implementation against the Validation Decision obligation established by MO-004b. |
| Review and accept MO-004b as a proposed derived requirement created from the evaluation and decomposition of MO-004. |
| Define the subject of each Validation Decision produced from a DIDO Baseline comparison. |
| Define how DIDO-TE identifies the applicable Validation Criteria. |
| Define the Authority responsible for establishing and approving the applicable Validation Criteria. |
| Define the permitted Validation Decision outcomes. |
| Define the rules for combining multiple Validation Criteria into one Validation Decision. |
| Define the treatment of unavailable or insufficient information. |
| Define the precedence and conflict-resolution rules for conflicting Validation Criteria. |
| Define the treatment of comparison results derived from Incomplete Test Runs for each applicable Test Run Termination Reason. |
| Define whether an authorized Actor must approve, affirm, or otherwise act on a Validation Decision produced by DIDO-TE. |
| Define the rationale DIDO-TE must record for each Validation Decision. |
| Define the Evidence DIDO-TE must preserve for each Validation Decision. |
| MO-004 — DIDO Baseline Comparison and Validation |
| Identify the authoritative source requirements, original requirement identifiers, and controlling citations for the DIDO Baseline comparison and Validation objective. |
| Review and approve the decomposition of MO-004 into MO-004a and MO-004b. |
| Determine whether MO-004a and MO-004b collectively supersede MO-004. |
| If MO-004a and MO-004b are accepted as the complete replacement for MO-004, mark MO-004 as superseded and preserve this page as the parent Traceability record. |
| Identify the authoritative source requirements, original requirement identifiers, and controlling citations for the DIDO Baseline comparison and Validation objective. |
| Determine whether DIDO Baseline requires a separate shared Terms and Definitions entry or identifies a DIDO-specific application of Baseline. |
| Determine whether Baseline Test Result requires a separate shared Terms and Definitions entry. |
| Define the criteria for selecting Test Results for inclusion in a DIDO Baseline. |
| Define the Validation Criteria and Validation Decision establishing that a Node is a validated Node. |
| Define the changes to a Node that cause the Node to be classified as a modified Node. |
| Define the relationship among the controlling DIDO Baseline, the selected Nodes, the modified Nodes, the selected Test Definition, the selected Test Environment, and the selected Test Runs. |
| Define the Test Result characteristics subject to comparison. |
| Define the comparison methods, measurement conditions, precision, exclusions, and tolerances. |
| Define how DIDO-TE classifies equality, difference, improvement, degradation, and inconclusive comparison results. |
| Define the treatment of missing, invalid, incomplete, incompatible, or unavailable DIDO Baseline Test Results. |
| Define the treatment of Incomplete Test Runs used to produce DIDO Baseline Test Results or comparison Test Results. |
| Define the effect of each applicable Test Run Termination Reason on DIDO Baseline comparison and Validation. |
| Define the Evidence required to support each comparison result and Validation Decision. |
| Determine whether MO-004a and MO-004b provide complete coverage of the approved intent of MO-004. |
| MO-006a — Application-Independent Testing |
| Assign the delivery phase for MO-006a. |
| Record the implementation status of MO-006a after reviewing the implementation plan. |
| The proposed derived requirement requires review and acceptance. |
| Confirm the controlling source statement and citation from which MO-006a derives. |
| Confirm which test elements must remain invariant across application implementations. |
| Define the permitted application-specific adaptations and their approval requirements. |
| Determine how verification distinguishes an application-specific adaptation from a change to the governing test. |
| MO-006b — Infrastructure-Independent Testing |
| Assign the delivery phase for MO-006b. |
| Record the implementation status of MO-006b after reviewing the implementation plan. |
| The proposed derived requirement requires review and acceptance. |
| Confirm the controlling source statement and citation from which MO-006b derives. |
| Confirm which test elements remain invariant across Infrastructure. |
| Define the permitted Infrastructure-specific adaptations and their approval requirements. |
| Determine which Infrastructure characteristics DIDO-TE records for each category of test. |
| Determine how verification distinguishes an Infrastructure-specific adaptation from a change to the governing test. |
| MO-006 — Application-Independent and Infrastructure-Independent Testing |
| Assign the delivery phase for MO-006. |
| Record the implementation status of MO-006 after reviewing the implementation plan. |
| The proposed derived requirement requires review and acceptance. |
| Confirm the controlling source statement and citation from which MO-006 derives. |
| Confirm whether application independence and infrastructure independence apply only to Test Definitions and Acceptance Criteria or also to test procedures, test data, metrics, and Evidence requirements. |
| Determine the permitted adaptations for application-specific and infrastructure-specific execution without weakening comparability. |
| Define how DIDO-TE records and approves deviations introduced by application-specific or infrastructure-specific test adaptations. |
| MO-007a — Connected Environment Operation |
| Assign the delivery phase for MO-007a. |
| Record the implementation status of MO-007a after reviewing the implementation plan. |
| The proposed derived requirement requires review and acceptance. |
| Confirm the testing operations included within the scope of Connected Environment operation. |
| Define how DIDO-TE identifies and authorizes permitted external network connections and services. |
| Determine which connectivity conditions DIDO-TE records for each test execution. |
| Determine how DIDO-TE records changes, interruptions, and failures involving external networks and services. |
| Confirm that MO-007a, together with MO-007b and MO-007c, preserves the complete approved intent of MO-007. |
| MO-007b — Disconnected Environment Operation |
| Assign the delivery phase for MO-007b. |
| Record the implementation status of MO-007b after reviewing the implementation plan. |
| The proposed derived requirement requires review and acceptance. |
| Confirm the testing operations included within the scope of Disconnected Environment operation. |
| Define how DIDO-TE verifies the absence of active External Network Connections during test execution. |
| Identify the authorized processes for transferring resources into and Test Results, logs, and Evidence out of a Disconnected Environment. |
| Determine whether Transfer Bundle preparation, validation, introduction, and removal require separate derived requirements beneath MO-007b. |
| Determine how DIDO-TE identifies and records dependencies upon External Services before disconnected test execution. |
| Confirm that MO-007b, together with MO-007a and MO-007c, preserves the complete approved intent of MO-007. |
| MO-007c — Air-Gapped Environment Operation |
| Assign the delivery phase for MO-007c. |
| Record the implementation status of MO-007c after reviewing the implementation plan. |
| The proposed derived requirement requires review and acceptance. |
| Confirm the testing operations included within the scope of Air-Gapped Environment operation. |
| Define how DIDO-TE verifies and records the physical isolation of the Air-Gapped Environment. |
| Identify the authorized processes for transferring resources into and Test Results, logs, and Evidence out of an Air-Gapped Environment. |
| Determine whether Transfer Bundle preparation, validation, introduction, and removal require separate derived requirements beneath MO-007c. |
| Identify the controls that prevent transfer operations from compromising the physical isolation of the Air-Gapped Environment. |
| Determine how DIDO-TE identifies and records dependencies upon External Services before air-gapped test execution. |
| Confirm that MO-007c, together with MO-007a and MO-007b, preserves the complete approved intent of MO-007. |
| MO-007 — Connected, Disconnected, and Air-Gapped Operation |
| Review and approve the decomposition of MO-007 into separate Connected Environment, Disconnected Environment, and Air-Gapped Environment requirements. |
| Determine whether MO-007a through MO-007c collectively supersede MO-007. |
| If MO-007a through MO-007c are accepted as the complete replacement for MO-007, mark MO-007 as superseded and preserve this page as the parent Traceability record. |
| Confirm the controlling source statement and citation for MO-007. |
| Confirm the titles and scope of MO-007a, MO-007b, and MO-007c. |
| Identify the testing operations DIDO-TE performs in each environment type. |
| Determine which testing operations apply uniformly across Connected, Disconnected, and Air-Gapped Environments. |
| Determine whether transfer operations require separate derived requirements beneath MO-007b and MO-007c. |
| Determine whether MO-007a through MO-007c provide complete coverage of the approved intent of MO-007. |
| MO-008a — Test Result Traceability |
| Assign the delivery phase for MO-008a. |
| Record the implementation status of MO-008a after reviewing the implementation plan. |
| The proposed derived requirement requires review and acceptance. |
| Confirm the minimum relationships required to establish Test Result Traceability. |
| Confirm whether Test Environment, configuration, test input, observation, and test outcome are existing defined concepts or require glossary entries. |
| Define the persistent identifier scheme used for Test Results and related records. |
| Determine the lifecycle period during which DIDO-TE maintains Test Result Traceability. |
| Determine whether Test Result Traceability includes the applicable requirements, acceptance criteria, test procedures, Candidate Solution version, and deployment baseline. |
| Confirm that MO-008a, together with MO-008b, preserves the complete intent of MO-008. |
| MO-008b — Evidence Traceability |
| Assign the delivery phase for MO-008b. |
| Record the implementation status of MO-008b after reviewing the implementation plan. |
| The proposed derived requirement requires review and acceptance. |
| Confirm the minimum relationships required to establish Evidence Traceability. |
| Determine the Evidence subjects that DIDO-TE recognizes, including Test Results, Observations, Test Environments, configurations, controls, execution conditions, and exceptions. |
| Define the persistent identifier scheme used for Evidence and related records. |
| Determine the lifecycle period during which DIDO-TE maintains Evidence Traceability. |
| Confirm the integrity and provenance information required for each type of Evidence. |
| Determine whether Evidence retention and chain-of-custody obligations require separate requirements. |
| Confirm that MO-008a and MO-008b collectively preserve the complete intent of MO-008. |
| MO-008 — Traceable Test Results and Evidence |
| Review and approve the decomposition of MO-008 into separate Test Result Traceability and Evidence Traceability requirements. |
| Determine whether MO-008a and MO-008b collectively supersede MO-008. |
| If MO-008a and MO-008b are accepted as the complete replacement for MO-008, mark MO-008 as superseded and preserve this page as the parent Traceability record. |
| Confirm the controlling DIDO-TE architectural or mission source from which MO-008 was derived. |
| Confirm the minimum relationships required to establish Traceability for each Test Result. |
| Confirm the minimum relationships required to establish Traceability for each Evidence item. |
| Determine whether DIDO-TE requires every Evidence item to substantiate a Test Result or whether Evidence also documents environments, configurations, controls, conditions, and exceptions. |
| Determine whether integrity, provenance, retention, and chain-of-custody obligations require separate requirements elsewhere in the requirements corpus. |
| Determine whether MO-008a and MO-008b provide complete coverage of the intent expressed by MO-008. |
| MO-009a — Test Resource Description |
| Assign the delivery phase for MO-009a. |
| Record the implementation status of MO-009a after reviewing the implementation plan. |
| The proposed derived requirement requires review and acceptance. |
| Define Test Resource in the shared Terms and Definitions corpus. |
| Confirm the classes of Test Resources governed by MO-009a. |
| Confirm the information required to identify a Test Resource. |
| Confirm the Test Resource types recognized by DIDO-TE. |
| Confirm how the description identifies supported uses and applicable constraints. |
| Determine whether the description must identify provenance, ownership, licensing, integrity information, compatibility information, and maintenance status. |
| Confirm whether each Test Resource requires a persistent unique identifier. |
| Confirm that MO-009a remains limited to Test Resource description and does not duplicate the control, applicability, or use Traceability obligations assigned to MO-009b through MO-009d. |
| MO-009b — Test Resource Control |
| Assign the delivery phase for MO-009b. |
| Record the implementation status of MO-009b after reviewing the implementation plan. |
| The proposed derived requirement requires review and acceptance. |
| Confirm the Test Resource control operations governed by MO-009b. |
| Confirm the actors authorized to create, modify, approve, release, withdraw, restore, and retire Test Resources. |
| Confirm the lifecycle states and availability statuses assigned to controlled Test Resources. |
| Confirm the integrity mechanism required for each controlled Test Resource type. |
| Confirm the provenance information required for each controlled Test Resource version. |
| Confirm the retention requirements for withdrawn, superseded, retired, and previously used Test Resource versions. |
| Confirm the conditions under which an authorized exception permits use of a withdrawn or otherwise unavailable Test Resource. |
| Confirm that MO-009b remains limited to Test Resource control and does not duplicate the description, applicability, or use Traceability obligations assigned to MO-009a, MO-009c, and MO-009d. |
| MO-009c — Test Resource Applicability |
| Assign the delivery phase for MO-009c. |
| Record the implementation status of MO-009c after reviewing the implementation plan. |
| The proposed derived requirement requires review and acceptance. |
| Confirm the testing-context characteristics that govern Test Resource applicability. |
| Confirm whether the applicability determination applies to a Test Definition, Candidate Solution, Test Environment, Test Execution, or a defined combination of these concepts. |
| Confirm the permitted applicability determinations and whether they include applicable, inapplicable, and conditionally applicable. |
| Confirm the conditions that require DIDO-TE to reassess Test Resource applicability. |
| Confirm who authorizes a Test Resource after DIDO-TE determines its applicability. |
| Confirm whether DIDO-TE requires an approved exception before using a conditionally applicable Test Resource. |
| Confirm the information DIDO-TE records as the basis for an applicability determination. |
| Confirm that MO-009c remains limited to Test Resource applicability and does not duplicate the description, control, or use Traceability obligations assigned to MO-009a, MO-009b, and MO-009d. |
| MO-009d — Test Resource Use Traceability |
| Assign the delivery phase for MO-009d. |
| Record the implementation status of MO-009d after reviewing the implementation plan. |
| The proposed derived requirement requires review and acceptance. |
| Confirm whether each Test Resource use record must identify the actor or automated mechanism that selected or supplied the Test Resource. |
| Confirm whether Traceability must extend directly to each Test Result, Verdict, and Evidence item or whether the relationship through the applicable Test Execution is sufficient. |
| Confirm the retention requirements for Test Resource use records. |
| Confirm that MO-009d remains limited to Test Resource use Traceability and does not duplicate the description, control, or applicability obligations assigned to MO-009a, MO-009b, and MO-009c. |
| MO-009 — Reusable Test Resources |
| Review and approve the decomposition of MO-009 into separate Test Resource description, control, applicability, and use Traceability requirements. |
| Determine whether MO-009a through MO-009d collectively supersede MO-009. |
| If MO-009a through MO-009d are accepted as the complete replacement for MO-009, mark MO-009 as superseded and preserve this page as the parent Traceability record. |
| Define Test Resource in the shared Terms and Definitions corpus. |
| Confirm the classes of Test Resources governed by MO-009. |
| Confirm the contexts across which DIDO-TE supports Test Resource reuse. |
| Determine whether Test Resource reuse includes controlled adaptation. |
| Confirm the information required to describe a reusable Test Resource. |
| Confirm the controls required to preserve Test Resource versions, integrity, provenance, and dependencies. |
| Confirm the conditions used to determine Test Resource applicability and compatibility. |
| Confirm the records required to establish Traceability for Test Resource use. |
| Confirm that MO-009a through MO-009d collectively preserve the complete intent of MO-009. |
| Confirm the controlling DIDO-TE architectural or mission source from which MO-009 was derived. |
| MO-001 — Governed Distributed Test Environments |
| TBD |
| Assess the current DIDO-TE implementation against MO-001 and its supporting Operational, Functional, Security, Logging and Auditing, and Data Management requirements. |
| Review and approve MO-001 as a proposed Mission Objective consolidated from the governance and Test Environment requirements in the draft DIDO-TE Requirements Register. |
| Define Governance in the shared DIDO Solutions Terms and Definitions corpus. |
| Define the governance hierarchy applicable to DIDO-TE Test Environments. |
| Define the relationship between a Test Environment and its governing Governance Domain. |
| Define whether each Test Environment has one primary governing Governance Domain or can have multiple governing Governance Domains. |
| Define the complete set of Test Environment operations governed by MO-001. |
| Define how DIDO-TE identifies the governing Authority for a Test Environment. |
| Define how DIDO-TE resolves Governance Policies inherited through the governance hierarchy. |
| Define the precedence and conflict-resolution rules for Governance Policies established by different Authorities or at different levels of the governance hierarchy. |
| Define the decision required when an applicable Governance Policy is missing, invalid, unavailable, or internally inconsistent. |
| Define the Governance Evidence DIDO-TE preserves for each governance decision and Test Environment operation. |
| Define the governance requirements applicable during each Test Environment Operational Lifecycle state and transition. |
| MO-003 — Automated Test Execution |
| Identify the authoritative source requirements, original requirement identifiers, and controlling citations for the automated Test Execution objective. |
| TBD |
| Assess the current DIDO-TE implementation against the automated Test Execution obligation established by MO-003. |
| Review and accept MO-003 as a proposed Mission Objective consolidated from the automated Test Execution intent in the DIDO-TE source material. |
| Identify the authoritative source requirements, original requirement identifiers, and controlling citations for automated Test Execution. |
| Define the event constituting initiation of automated Test Execution. |
| Define the event constituting completion of automated Test Execution. |
| Define the human activities permitted before Test Execution initiation. |
| Define the human control operations permitted after Test Execution initiation. |
| Define whether every Test Step in the selected Test Execution must be automated. |
| Define the required behavior when the selected Test Definition contains a Test Step requiring human performance. |
| Define the required behavior when an applicable Test Executable or Execution Facility is unavailable. |
| Identify the Test Execution Exceptions DIDO-TE must detect during automated Test Execution. |
| Define the Exception Handling applicable to each Test Execution Exception. |
| Define the retry, pause, cancellation, termination, compensation, and recovery operations permitted during automated Exception Handling. |
| Define which Exception Handling operations can require human intervention. |
| Define the treatment of Incomplete Test Runs for each applicable Test Run Termination Reason. |
| Define the Test Results and Evidence DIDO-TE must produce during automated Test Execution. |
| MO-005 — Comparative Evaluation of Candidate Solutions |
| Identify the authoritative source requirements, original requirement identifiers, and controlling citations for the comparative evaluation of Candidate Solutions. |
| TBD |
| Assess the current DIDO-TE implementation against the comparative evaluation obligation established by MO-005. |
| Review and accept MO-005 as a proposed Mission Objective consolidated from the comparative-evaluation intent in the DIDO-TE source material. |
| Identify the authoritative source requirements, original requirement identifiers, and controlling citations for the comparative evaluation of Candidate Solutions. |
| Define Candidate Solution in the shared Terms and Definitions corpus. |
| Determine whether Comparative Evaluation requires a separate shared Terms and Definitions entry. |
| Define the Candidate Solution characteristics subject to comparative evaluation. |
| Define the common evaluation basis used for selected Candidate Solutions. |
| Define the characteristics held constant and the characteristics permitted to vary among Candidate Solution evaluations. |
| Define the supported comparison methods. |
| Define the measurement conditions, units, precision, exclusions, and tolerances used for each evaluated characteristic. |
| Define the rules for normalizing measurements produced by different Candidate Solutions. |
| Define the rules for combining evaluation characteristics. |
| Define the treatment of missing, invalid, incompatible, or unavailable information. |
| Define the treatment of nondeterministic behavior. |
| Define the treatment of Incomplete Test Runs for each applicable Test Run Termination Reason. |
| Define the permitted comparative-evaluation outcomes. |
| Determine whether MO-005 permits DIDO-TE to rank Candidate Solutions. |
| Determine whether MO-005 permits DIDO-TE to recommend or select a preferred Candidate Solution. |
| Define the Evidence DIDO-TE must preserve for each comparative evaluation. |
| C.2 Operational Requirements |
| Derive the Operational Requirements from the applicable source requirements, governance constraints, operational concepts, and ConOps material before creating individual OPR requirement pages. |
| Add explicit links to proposed OPR requirement pages under Contents while the requirement set is being created. Remove the explicit links after the pages are finalized because the indexmenu automatically discovers them. |
| NOD-004a — Establish the Initial Node State |
| Assign the applicable delivery phase. |
| NOD-004b — Start the Node |
| Assign the applicable delivery phase. |
| NOD-004c — Confirm Node Readiness |
| Assign the applicable delivery phase. |
| NOD-004d — Transition the Node State |
| Assign the applicable delivery phase. |
| NOD-004e — Stop the Node |
| Assign the applicable delivery phase. |
| NOD-004g — Handle a Node Lifecycle Exception |
| Assign the applicable delivery phase. |
| NOD-004h — Record Node Lifecycle Activity |
| Assign the applicable delivery phase. |
| NOD-004 — Control the Node Lifecycle |
| Assign the applicable delivery phase. |
| NOD-005a — Authorize Node Execution |
| Assign the applicable delivery phase. |
| NOD-005b — Initiate Node Execution |
| Assign the applicable delivery phase. |
| NOD-005c — Provide Node Inputs |
| Assign the applicable delivery phase. |
| NOD-005d — Observe Node Execution |
| Assign the applicable delivery phase. |
| NOD-005e — Control Node Execution |
| Assign the applicable delivery phase. |
| NOD-005f — Handle a Node Execution Exception |
| Assign the applicable delivery phase. |
| NOD-005g — Complete Node Execution |
| Assign the applicable delivery phase. |
| NOD-005h — Record Node Execution |
| Assign the applicable delivery phase. |
| NOD-005 — Execute a Node |
| Assign the applicable delivery phase. |
| NOD-006 — Isolate a Node |
| Assign the applicable delivery phase. |
| Assign the implementation status. |
| The proposed derived requirement requires review and acceptance. |
| Assign the source requirement identifier and obligation from the DIDO-TE Requirements Register. |
| NOD-007 — Identify a Node |
| Assign the applicable delivery phase. |
| Assign the implementation status. |
| The proposed derived requirement requires review and acceptance. |
| Assign the source requirement identifier and obligation from the DIDO-TE Requirements Register. |
| Specify the identification scope within which each Node identifier must be unique. |
| NOD-008a — Establish Node Observation |
| Assign the delivery phase. |
| Assign the implementation status. |
| The proposed derived requirement requires review and acceptance. |
| Assign the source requirement identifier and obligation from the DIDO-TE Requirements Register. |
| NOD-008b — Observe Node State |
| Assign the delivery phase. |
| Assign the implementation status. |
| The proposed derived requirement requires review and acceptance. |
| Assign the source requirement identifier and obligation from the DIDO-TE Requirements Register. |
| NOD-008d — Observe Node Resource Use |
| Assign the delivery phase. |
| Assign the implementation status. |
| The proposed derived requirement requires review and acceptance. |
| Assign the source requirement identifier and obligation from the DIDO-TE Requirements Register. |
| NOD-008 — Observe a Node |
| Assign the applicable delivery phase. |
| Implementation status derives from the implementation status of the child requirements. |
| The proposed derived requirement and its decomposition require review and acceptance. |
| Assign the source requirement identifier and obligation from the DIDO-TE Requirements Register. |
| NOD-009a — Establish Node Resource Controls |
| Assign the delivery phase. |
| Assign the implementation status. |
| The proposed derived requirement requires review and acceptance. |
| Assign the source requirement identifier and obligation from the DIDO-TE Requirements Register. |
| NOD-009b — Allocate Node Resources |
| Assign the delivery phase. |
| Assign the implementation status. |
| The proposed derived requirement requires review and acceptance. |
| Assign the source requirement identifier and obligation from the DIDO-TE Requirements Register. |
| NOD-009c — Control Node Resource Use |
| Assign the delivery phase. |
| Assign the implementation status. |
| The proposed derived requirement requires review and acceptance. |
| Assign the source requirement identifier and obligation from the DIDO-TE Requirements Register. |
| NOD-009d — Handle a Node Resource-Control Exception |
| Assign the delivery phase. |
| Assign the implementation status. |
| The proposed derived requirement requires review and acceptance. |
| Assign the source requirement identifier and obligation from the DIDO-TE Requirements Register. |
| NOD-009e — Release Node Resources |
| Assign the delivery phase. |
| Assign the implementation status. |
| The proposed derived requirement requires review and acceptance. |
| Assign the source requirement identifier and obligation from the DIDO-TE Requirements Register. |
| NOD-009f — Record Node Resource Control |
| Assign the delivery phase. |
| Assign the implementation status. |
| The proposed derived requirement requires review and acceptance. |
| Assign the source requirement identifier and obligation from the DIDO-TE Requirements Register. |
| NOD-009 — Control Node Resources |
| Assign the delivery phase. |
| Implementation status derives from the implementation status of the child requirements. |
| The proposed derived requirement and its decomposition require review and acceptance. |
| Assign the source requirement identifier and obligation from the DIDO-TE Requirements Register. |
| NOD-010a — Specify a Node Fault |
| Assign the delivery phase. |
| Assign the implementation status. |
| The proposed derived requirement requires review and acceptance. |
| Assign the source requirement identifier and obligation from the DIDO-TE Requirements Register. |
| NOD-010b — Authorize Node Fault Injection |
| Assign the delivery phase. |
| Assign the implementation status. |
| The proposed derived requirement requires review and acceptance. |
| Assign the source requirement identifier and obligation from the DIDO-TE Requirements Register. |
| NOD-010c — Prepare Node Fault Injection |
| Assign the delivery phase. |
| Assign the implementation status. |
| The proposed derived requirement requires review and acceptance. |
| Assign the source requirement identifier and obligation from the DIDO-TE Requirements Register. |
| NOD-010d — Inject a Node Fault |
| Assign the delivery phase. |
| Assign the implementation status. |
| The proposed derived requirement requires review and acceptance. |
| Assign the source requirement identifier and obligation from the DIDO-TE Requirements Register. |
| NOD-010e — Control a Node Fault |
| Assign the delivery phase. |
| Assign the implementation status. |
| The proposed derived requirement requires review and acceptance. |
| Assign the source requirement identifier and obligation from the DIDO-TE Requirements Register. |
| NOD-010f — Recover from a Node Fault |
| Assign the delivery phase. |
| Assign the implementation status. |
| The proposed derived requirement requires review and acceptance. |
| Assign the source requirement identifier and obligation from the DIDO-TE Requirements Register. |
| NOD-010g — Record Node Fault Injection |
| Assign the delivery phase. |
| Assign the implementation status. |
| The proposed derived requirement requires review and acceptance. |
| Assign the source requirement identifier and obligation from the DIDO-TE Requirements Register. |
| NOD-010 — Inject Node Faults |
| Assign the delivery phase. |
| Implementation status derives from the implementation status of the child requirements. |
| The proposed derived requirement and its decomposition require review and acceptance. |
| Assign the source requirement identifier and obligation from the DIDO-TE Requirements Register. |
| Determine whether Fault, Fault Injection, and Injection Point require controlled Terms and Definitions entries before finalizing the child requirements. |
| NOD-011a — Specify Node State Preservation |
| Assign the delivery phase. |
| Assign the implementation status. |
| The proposed derived requirement requires review and acceptance. |
| Assign the source requirement identifier and obligation from the DIDO-TE Requirements Register. |
| NOD-011b — Capture Node State |
| Assign the delivery phase. |
| Assign the implementation status. |
| The proposed derived requirement requires review and acceptance. |
| Assign the source requirement identifier and obligation from the DIDO-TE Requirements Register. |
| NOD-011c — Protect Preserved Node State |
| Assign the delivery phase. |
| Assign the implementation status. |
| The proposed derived requirement requires review and acceptance. |
| Assign the source requirement identifier and obligation from the DIDO-TE Requirements Register. |
| NOD-011d — Verify Preserved Node State |
| Assign the delivery phase. |
| Assign the implementation status. |
| The proposed derived requirement requires review and acceptance. |
| Assign the source requirement identifier and obligation from the DIDO-TE Requirements Register. |
| NOD-011e — Retain Preserved Node State |
| Assign the delivery phase. |
| Assign the implementation status. |
| The proposed derived requirement requires review and acceptance. |
| Assign the source requirement identifier and obligation from the DIDO-TE Requirements Register. |
| NOD-011f — Restore Preserved Node State |
| Assign the delivery phase. |
| Assign the implementation status. |
| The proposed derived requirement requires review and acceptance. |
| Assign the source requirement identifier and obligation from the DIDO-TE Requirements Register. |
| NOD-011g — Dispose of Preserved Node State |
| Assign the delivery phase. |
| Assign the implementation status. |
| The proposed derived requirement requires review and acceptance. |
| Assign the source requirement identifier and obligation from the DIDO-TE Requirements Register. |
| NOD-011h — Record Node State Preservation |
| Assign the delivery phase. |
| Assign the implementation status. |
| The proposed derived requirement requires review and acceptance. |
| Assign the source requirement identifier and obligation from the DIDO-TE Requirements Register. |
| NOD-011 — Preserve Node State |
| Assign the delivery phase. |
| Implementation status derives from the implementation status of the child requirements. |
| The proposed derived requirement and its decomposition require review and acceptance. |
| Assign the source requirement identifier and obligation from the DIDO-TE Requirements Register. |
| Determine whether Preserved Node State requires a controlled Terms and Definitions entry before finalizing the child requirements. |
| NOD-012 — Reset a Node |
| Assign the delivery phase. |
| Assign the implementation status. |
| The proposed derived requirement requires review and acceptance. |
| Assign the source requirement identifier and obligation from the DIDO-TE Requirements Register. |
| Determine whether Reset requires a controlled Terms and Definitions entry. |
| NOD-013 — Maintain Node Traceability |
| Assign the delivery phase. |
| Assign the implementation status. |
| The proposed derived requirement requires review and acceptance. |
| Assign the source requirement identifier and obligation from the DIDO-TE Requirements Register. |
| Annex C: Requirements |
| Remove the explicit creation links under Contents after all planned requirement-category pages have been created and the indexmenu discovers them. |