| Next revision | Previous revision |
| dido:02-crusible:99-annexes:annex-c-requirements:01-mission-objectives:mo-005:start [2026/07/15 12:51] – created nick_dido | dido:02-crusible:99-annexes:annex-c-requirements:01-mission-objectives:mo-005:start [2026/07/22 12:20] (current) – nick_dido |
|---|
| ====== MO-005 ====== | ====== MO-005 — Reusable and Version-Controlled Infrastructure Baselines ====== |
| |
| [[dido:02-crusible:99-annexes:annex-c-requirements:01-mission-objectives:start|Go to Mission Objectives]] | [[dido:02-crusible:99-annexes:annex-c-requirements:01-mission-objectives:start|Go to Mission Objectives]] |
| |
| ===== Statement ===== | ===== Original Requirement ===== |
| |
| [[dido:99_annexes:annex-b-terms-and-definitions:c:crucible|Crucible]] SHALL maintain each [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_baseline|Infrastructure Baseline]] as a uniquely identified, [[dido:99_annexes:annex-b-terms-and-definitions:v:version_control|version-controlled]] [[dido:99_annexes:annex-b-terms-and-definitions:a:artifact|Artifact]] that can be selected and applied to more than one [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_deployment|Infrastructure Deployment]] without modifying the approved baseline content. | > //The system SHALL establish infrastructure as a reusable and version-controlled asset.//[[dido:02-crusible:99-annexes:annex-b:cr-001|[C1]]] |
| |
| ===== Source Statement ===== | ===== Assessment of Original Requirement ===== |
| |
| > The system SHALL establish infrastructure as a reusable and version-controlled asset. | The Original Requirement preserves the approved mission objective but does not express independently testable normative statements. |
| | |
| ===== Source ===== | |
| | |
| Crucible System Requirements Specification, Version 1.1 Draft, Mission Objectives, MO-005. | |
| | |
| ===== Assessment ===== | |
| | |
| The source statement expresses the approved mission objective but does not provide a fully testable formulation. | |
| |
| The following Specification Discipline and Authoring findings apply: | The following Specification Discipline and Authoring findings apply: |
| |
| * **The system** does not use the defined system name | * **The system** does not use the defined system name [[dido:99_annexes:annex-b-terms-and-definitions:c:crucible|Crucible]] |
| * **Establish** does not identify the lifecycle behavior that [[dido:99_annexes:annex-b-terms-and-definitions:c:crucible|Crucible]] performs | * **Establish** is a weak verb that does not identify an observable behavior performed by Crucible |
| * **Infrastructure** does not identify whether the requirement applies to an [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_baseline|Infrastructure Baseline]], deployed infrastructure, infrastructure configuration, or another infrastructure representation | * **Infrastructure** does not identify the managed subject as an [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_baseline|Infrastructure Baseline]] |
| * **Reusable** does not identify the number of uses, permitted variation, selection criteria, or conditions under which reuse occurs | * **Asset** does not use the defined concept [[dido:99_annexes:annex-b-terms-and-definitions:a:artifact|Artifact]] |
| * **Version-controlled** does not identify the required revision identifier, revision history, repository record, or relationship between revisions | * **Reusable** does not identify the required reuse behavior |
| * **Asset** does not identify the information, configuration, provenance, and lifecycle records that constitute the managed asset | * **Version-controlled** combines several independently testable behaviors without identifying them separately |
| * The source statement does not distinguish modification of an approved baseline from selection and reuse of that baseline | |
| |
| The normalized Statement replaces **establish** with **maintain**, identifies the managed [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_baseline|Infrastructure Baseline]], and defines reuse as application to more than one [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_deployment|Infrastructure Deployment]] without modifying the approved baseline content. | The Original Requirement does not identify: |
| |
| ===== Rationale ===== | * How Crucible manages an Infrastructure Baseline as an Artifact |
| | * How Crucible uniquely identifies each Infrastructure Baseline |
| | * How Crucible distinguishes Infrastructure Baseline revisions |
| | * How an approved Infrastructure Baseline revision is selected for an [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_deployment|Infrastructure Deployment]] |
| | * The minimum number of Infrastructure Deployments required to demonstrate reuse |
| | * Whether approved Infrastructure Baseline content may change during reuse |
| | * How each Infrastructure Deployment identifies the Infrastructure Baseline revision used |
| |
| Infrastructure definitions that exist only as deployment-specific scripts or manually maintained configurations cannot be reliably reused, compared, governed, or reproduced. | The Original Requirement therefore requires: |
| |
| [[dido:99_annexes:annex-b-terms-and-definitions:c:crucible|Crucible]] treats each [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_baseline|Infrastructure Baseline]] as a managed [[dido:99_annexes:annex-b-terms-and-definitions:a:artifact|Artifact]] with: | * Replacement of **the system** with the defined system name [[dido:99_annexes:annex-b-terms-and-definitions:c:crucible|Crucible]] |
| | * Replacement of **establish** with observable Crucible behavior |
| | * Identification of the managed subject as an Infrastructure Baseline |
| | * Management of each Infrastructure Baseline as an Artifact |
| | * Unique identification of each Infrastructure Baseline |
| | * Identification and preservation of Infrastructure Baseline revisions |
| | * Selection of an approved Infrastructure Baseline revision for Infrastructure Deployment |
| | * Reuse of an Infrastructure Baseline revision across multiple Infrastructure Deployments |
| | * Preservation of approved Infrastructure Baseline content during reuse |
| | * Traceability from each Infrastructure Deployment to the Infrastructure Baseline revision used |
| | * Confirmation that the derived requirements collectively preserve the complete intent of MO-005 |
| |
| * A stable identifier | The decomposition preserves ''MO-005'' as the stable parent requirement identifier. Each proposed replacement requirement receives a lettered identifier and a separate leaf requirement page. |
| * A revision identifier | |
| * A revision history | |
| * Defined source content | |
| * [[dido:99_annexes:annex-b-terms-and-definitions:p:provenance|Provenance]] | |
| * Approval status | |
| * Selection criteria | |
| * Relationships to preceding and succeeding revisions | |
| * Relationships to the [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_deployment|Infrastructure Deployments]] that use the baseline | |
| |
| This treatment permits multiple deployments to use the same approved baseline while preserving the distinction between: | ===== Proposed Statements ===== |
| |
| * Reusing an approved baseline | The Original Requirement is decomposed into the following proposed replacement requirements: |
| * Creating a new baseline revision | |
| * Applying platform specific parameters | |
| * Recording deployment-specific state | |
| |
| [[dido:99_annexes:annex-b-terms-and-definitions:v:version_control|Version Control]] preserves the baseline history and supports comparison, rollback, audit, [[dido:99_annexes:annex-b-terms-and-definitions:r:reproducibility|Reproducibility]], and [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceability]] throughout the [[dido:99_annexes:annex-b-terms-and-definitions:o:operational_lifecycle|Operational Lifecycle]]. | {{indexmenu>dido:02-crusible:99-annexes:annex-c-requirements:01-mission-objectives:mo-005#1|js navbar nocookie maxjs#1 id#crucible_mo_005_requirements_nav}} |
| |
| ===== Applies To ===== | ===== Requirement Status ===== |
| |
| This requirement applies to: | <todo>Review and approve the proposed decomposition of MO-005 into independently testable Infrastructure Baseline management, identification, revision-control, selection, reuse, preservation, and Traceability requirements.</todo> |
| |
| * [[dido:99_annexes:annex-b-terms-and-definitions:c:crucible|Crucible]] | <todo>Determine whether MO-005a through MO-005g collectively supersede MO-005.</todo> |
| * [[dido:99_annexes:annex-b-terms-and-definitions:c:crucible_description|Crucible Descriptions]] | |
| * [[dido:99_annexes:annex-b-terms-and-definitions:b:baseline|Baselines]] | |
| * [[dido:99_annexes:annex-b-terms-and-definitions:b:baseline_composition|Baseline Composition]] | |
| * [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_baseline|Infrastructure Baselines]] | |
| * [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_deployment|Infrastructure Deployments]] | |
| * [[dido:99_annexes:annex-b-terms-and-definitions:a:artifact|Artifacts]] | |
| * [[dido:99_annexes:annex-b-terms-and-definitions:v:version_control|Version Control]] | |
| * [[dido:99_annexes:annex-b-terms-and-definitions:r:revision|Revisions]] | |
| * [[dido:99_annexes:annex-b-terms-and-definitions:r:revision_history|Revision History]] | |
| * [[dido:99_annexes:annex-b-terms-and-definitions:p:provenance|Provenance]] | |
| * [[dido:99_annexes:annex-b-terms-and-definitions:c:configuration_management|Configuration Management]] | |
| * [[dido:99_annexes:annex-b-terms-and-definitions:r:reproducibility|Reproducibility]] | |
| * [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceability]] | |
| * [[dido:99_annexes:annex-b-terms-and-definitions:c:ci_cd_pipeline|CI/CD Pipelines]] | |
| * [[dido:99_annexes:annex-b-terms-and-definitions:o:operational_lifecycle|Operational Lifecycle]] | |
| |
| ===== Verification ===== | <todo>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.</todo> |
| |
| - Verification SHALL confirm that each tested [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_baseline|Infrastructure Baseline]] has a unique identifier | ---- |
| - Verification SHALL confirm that each tested [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_baseline|Infrastructure Baseline]] has a revision identifier | ===== Issues ===== |
| - Verification SHALL confirm that the applicable [[dido:99_annexes:annex-b-terms-and-definitions:v:version_control|Version Control]] system preserves the content associated with each baseline revision | |
| - Verification SHALL confirm that the applicable [[dido:99_annexes:annex-b-terms-and-definitions:v:version_control|Version Control]] system preserves the relationship between successive baseline revisions | |
| - Verification SHALL confirm that the same approved [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_baseline|Infrastructure Baseline]] can be selected for more than one [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_deployment|Infrastructure Deployment]] | |
| - Verification SHALL confirm that reuse of the approved [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_baseline|Infrastructure Baseline]] does not modify the approved baseline content | |
| - Verification SHALL confirm that changes to approved baseline content create a separately identified revision | |
| - Verification SHALL confirm that each tested [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_deployment|Infrastructure Deployment]] records the identifier and revision of the selected [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_baseline|Infrastructure Baseline]] | |
| - Verification SHALL confirm that platform specific parameters remain distinguishable from the approved baseline content | |
| - Verification SHALL confirm that the baseline record preserves the applicable [[dido:99_annexes:annex-b-terms-and-definitions:p:provenance|Provenance]] | |
| - Verification SHALL confirm that an authorized user can retrieve a prior baseline revision | |
| - Verification SHALL confirm that an authorized user can compare two baseline revisions | |
| - Verification SHALL confirm that baseline reuse and revision records preserve [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceability]] | |
| |
| Verification may include: | The following unresolved issues affect the decomposition of MO-005: |
| |
| * Baseline identifier inspection | <todo>Define the Artifact-management requirements that apply to an Infrastructure Baseline.</todo> |
| * Revision identifier inspection | |
| * Repository history inspection | |
| * Baseline content comparison | |
| * Revision comparison | |
| * Repeated deployment tests | |
| * Cross platform deployment tests | |
| * Baseline selection tests | |
| * Baseline immutability tests | |
| * Provenance record inspection | |
| * Deployment record inspection | |
| * Prior revision retrieval tests | |
| * End-to-end [[dido:99_annexes:annex-b-terms-and-definitions:c:ci_cd_pipeline|CI/CD Pipeline]] tests | |
| |
| The verification record SHALL identify: | <todo>Define the identifier assigned to each Infrastructure Baseline and the authority responsible for assigning it.</todo> |
| |
| - The tested [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_baseline|Infrastructure Baseline]] | <todo>Define the revision identifier, revision sequence, and change-control rules for Infrastructure Baselines.</todo> |
| - The baseline identifier | |
| - The baseline revision identifier | |
| - The baseline source location | |
| - The baseline approval status | |
| - The preceding revision | |
| - The succeeding revision, when applicable | |
| - The tested [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_deployment|Infrastructure Deployments]] | |
| - The platform specific parameters | |
| - The content comparison result | |
| - The revision comparison result | |
| - The applicable [[dido:99_annexes:annex-b-terms-and-definitions:p:provenance|Provenance]] | |
| - The observed results | |
| - The generated [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]] | |
| |
| ===== Outgoing Traceability ===== | <todo>Define the approval authority and approval status required before an Infrastructure Baseline revision may be selected for Infrastructure Deployment.</todo> |
| |
| This requirement is realized by: | <todo>Define the minimum number of Infrastructure Deployments required to demonstrate Infrastructure Baseline reuse.</todo> |
| |
| * [[dido:02-crusible:99-annexes:annex-c-requirements:03-functional-requirements:03-01-configuration-management:start|FR-CFG-001 through FR-CFG-005]] | <todo>Define whether reuse requires identical Controlled Inputs other than deployment-specific parameters.</todo> |
| * [[dido:02-crusible:99-annexes:annex-c-requirements:03-functional-requirements:03-08-devsecops-integration:start|FR-DSO-001 through FR-DSO-006]] | |
| * [[dido:02-crusible:99-annexes:annex-c-requirements:03-functional-requirements:03-09-baseline-composition-and-workspace:start|FR-BAS-001 through FR-BAS-004]] | |
| * [[dido:02-crusible:99-annexes:annex-c-requirements:09-maintainability-requirements:start|MAINT-001 through MAINT-005]] | |
| * [[dido:02-crusible:99-annexes:annex-c-requirements:10-data-management-requirements:start|DATA-001 through DATA-005]] | |
| * [[dido:02-crusible:99-annexes:annex-c-requirements:13-key-value-proposition-requirements:kvp-003:start|KVP-003 — Improve deployment repeatability]] | |
| * [[dido:02-crusible:99-annexes:annex-c-requirements:13-key-value-proposition-requirements:kvp-005:start|KVP-005 — Reduce configuration drift]] | |
| |
| This requirement also relates to: | <todo>Define the behavior required when a change to an approved Infrastructure Baseline is necessary.</todo> |
| |
| * [[dido:02-crusible:05-descriptions-composition-and-baselines:start|5. Descriptions, Composition, and Baselines]] | <todo>Define the Traceability record that associates each Infrastructure Deployment with the Infrastructure Baseline identifier and revision used.</todo> |
| * [[dido:02-crusible:07-infrastructure-and-deployment:start|7. Infrastructure and Deployment]] | |
| * [[dido:02-crusible:10-reproducibility-provenance-and-traceability:start|10. Reproducibility, Provenance, and Traceability]] | |
| |
| ===== Referenced By ===== | <todo>Determine whether MO-005a through MO-005g provide complete coverage of the approved intent of MO-005.</todo> |
| |
| The wiki Backlinks function provides the current list of pages that reference `MO-005`. | ---- |
| | ===== Notes for Editors ===== |
| |
| Incoming traceability should be derived dynamically from backlinks rather than maintained as a duplicate manual list. | This page should retain the stable parent requirement identifier ''MO-005''. |
| |
| Backlinks identify incoming references but do not define the semantics of each relationship. Referencing pages should identify whether the relationship represents realization, refinement, verification, dependency, or another defined traceability relationship. | This page is a non-leaf requirement page and retains a trailing '':start'' in its namespace. |
| |
| ===== ConOps Relationship ===== | The child requirements are leaf requirement pages and omit a trailing '':start'' from their namespaces. |
| |
| The Crucible Concept of Operations describes [[dido:99_annexes:annex-b-terms-and-definitions:b:baseline_composition|Baseline Composition]] as the use of versioned Image Layer and [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_baseline|Infrastructure Baseline]] repositories alongside consumer source within a [[dido:99_annexes:annex-b-terms-and-definitions:c:ci_cd_pipeline|CI/CD Pipeline]] workspace. | The explicit child-page links should remain while the proposed decomposition is being developed. After the child pages have been created and finalized, the explicit links may be removed because the ''indexmenu'' displays the child requirement pages contained within the MO-005 namespace. |
| |
| The Phase 1 workflow: | This page preserves: |
| |
| * Selects the required baseline repositories | * The Original Requirement |
| * Retrieves the identified baseline revisions | * The assessment of the Original Requirement |
| * Composes the selected baselines within the workspace | * The reason for decomposition |
| * Applies the selected [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_baseline|Infrastructure Baseline]] | * [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceability]] to the proposed replacement requirements |
| * Records the source revision identifiers | * The unresolved cross-cutting issues affecting the decomposition |
| * Performs [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_deployment|Infrastructure Deployment]] | * The supersession decision |
| * Preserves deployment history and [[dido:99_annexes:annex-b-terms-and-definitions:p:provenance|Provenance]] | |
| |
| The ConOps permits a composition to contain application source, Image Layers, Infrastructure Baselines, or a combination of these inputs. A composition that contains only Image Layers or Infrastructure Baselines remains valid. | The derived requirements should distinguish: |
| |
| This operational model treats an [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_baseline|Infrastructure Baseline]] as a reusable and versioned deployment input rather than a deployment-specific script or manually recreated configuration. | * Management of an Infrastructure Baseline as an Artifact |
| | * Identification of an Infrastructure Baseline |
| ===== Delivery Phase ===== | * Identification and control of Infrastructure Baseline revisions |
| | * Approval and selection of an Infrastructure Baseline revision |
| Phase 1 and subsequent phases | * Reuse of an Infrastructure Baseline revision |
| | * Preservation of approved Infrastructure Baseline content |
| ===== Implementation Status ===== | * Traceability from an Infrastructure Deployment to the Infrastructure Baseline revision used |
| | |
| Not Assessed | |
| | |
| Implementation status requires verification that approved [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_baseline|Infrastructure Baselines]] are uniquely identified, version controlled, reusable across multiple deployments, and traceable to the deployments that use them. | |
| | |
| ===== Requirement Status ===== | |
| | |
| Draft | |
| | |
| The source System Requirements Specification identifies Version 1.1 as a draft. | |
| | |
| ---- | |
| ===== Notes for Editors ===== | |
| |
| This requirement page should retain the stable requirement identifier `MO-005`. | Reuse does not mean modification of an approved Infrastructure Baseline revision. A required change should produce a new controlled revision rather than alter the approved revision already used by prior Infrastructure Deployments. |
| |
| Changes to the Statement SHALL preserve the approved intent of the source requirement. | Infrastructure Baseline identification and Infrastructure Baseline revision identification are separate concerns. The baseline identifier identifies the managed baseline, while the revision identifier distinguishes one controlled state of that baseline from another. |
| |
| Material changes should receive review and should update the related outbound traceability, verification criteria, acceptance criteria, and source records. | The Original Requirement should not be marked as superseded until the requirement owner: |
| |
| The Source Statement should preserve the original wording from the controlling System Requirements Specification. | * Approves the proposed decomposition |
| | * Approves the child requirements |
| | * Defines the Infrastructure Baseline identification and revision-control rules |
| | * Defines the approval and selection process |
| | * Defines the minimum reuse condition |
| | * Defines the preservation and change-control rules |
| | * Defines the required Infrastructure Deployment Traceability record |
| | * Confirms that the child requirements collectively preserve the complete approved intent of MO-005 |
| | * Confirms that no additional child requirements are required |
| |
| Incoming traceability should use the wiki Backlinks function rather than a manually maintained list. | After supersession, this page should remain as the parent Traceability record and should continue to preserve the Original Requirement and its assessment. |
| |
| Do not rename this page once it has been cited externally unless a redirect or move plan is in place. | Material changes to the decomposition should update the child requirements, Requirement Status, Issues, and Traceability records. |
| |
| ---- | ---- |