MO-005 — Reusable and Version-Controlled Infrastructure

Go to Mission Objectives

Crucible SHALL maintain each Infrastructure Baseline as a uniquely identified, version-controlled Artifact that can be selected and applied to two or more Infrastructure Deployments without modifying the approved baseline content.

The system SHALL establish infrastructure as a reusable and version-controlled asset.

Crucible System Requirements Specification, Version 1.1 Draft, Mission Objectives, MO-005.

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 system does not use the defined system name
• Establish does not identify the lifecycle behavior that Crucible performs
• Infrastructure does not identify whether the requirement applies to an Infrastructure Baseline, deployed infrastructure, infrastructure configuration, or another infrastructure representation
• Reusable does not identify the minimum number of uses, permitted variation, selection criteria, or conditions under which reuse occurs
• Version-controlled does not identify the required revision identifier, revision history, repository record, or relationship between revisions
• Asset does not identify the managed Artifact, its Artifact Catalog Record, or the information required to govern the Artifact throughout its lifecycle
• The source statement does not distinguish modification of an approved baseline from selection and reuse of that baseline
• The source statement does not require a deployment to record the baseline identifier and revision that it uses

The normalized Statement replaces establish with maintain, identifies the managed Infrastructure Baseline, defines reuse as application to two or more deployments, and prohibits reuse from modifying approved baseline content.

Infrastructure definitions that exist only as deployment-specific scripts or manually maintained configurations cannot be reliably reused, compared, governed, or reproduced.

Crucible treats each Infrastructure Baseline as a managed Artifact and maintains an Artifact Catalog Record for the Infrastructure Baseline.

The Artifact Catalog Record describes the Infrastructure Baseline and its managed lifecycle information, including:

• The stable Artifact identifier
• The applicable revision identifier
• The revision history
• The defined source content
• Provenance
• Approval status
• Selection criteria
• Relationships to preceding and succeeding revisions
• Relationships to the Infrastructure Deployments that use the baseline

This treatment permits multiple deployments to use the same approved baseline while preserving the distinction between:

• Reusing an approved baseline
• Creating a new baseline revision
• Applying Platform Specific Parameters
• Recording deployment-specific state
• Recording locally authorized configuration changes

Version Control preserves baseline content and revision history. The Artifact Catalog Record preserves the managed information and relationships associated with each baseline revision.

Together, Version Control and the Artifact Catalog Record support comparison, rollback, Auditability, Reproducibility, and Traceability throughout the Operational Lifecycle.

A deployment record identifies the exact Infrastructure Baseline revision used for an environment and references the applicable Artifact Catalog Record. This relationship allows an organization to determine which environments use a baseline revision and which deployments may require review when that baseline changes.

This requirement applies to:

• Crucible
• Crucible Descriptions
• Baselines
• Baseline Composition
• Infrastructure Baselines
• Infrastructure Deployments
• Artifacts
• Artifact Catalog Records
• Artifact Catalog
• Version Control
• Revisions
• Revision History
• Baseline Approval
• Baseline Selection
• Baseline Reuse
• Baseline Immutability
• Platform Specific Parameters
• Provenance
• Configuration Management
• Reproducibility
• Auditability
• Traceability
• CI/CD Pipelines
• Operational Lifecycle

1. Verification SHALL confirm that each tested Infrastructure Baseline has an Artifact Catalog Record
2. Verification SHALL confirm that each tested Artifact Catalog Record identifies the Infrastructure Baseline using a unique Artifact identifier
3. Verification SHALL confirm that each tested Artifact Catalog Record identifies the applicable baseline revision
4. Verification SHALL confirm that the applicable Version Control system preserves the content associated with each baseline revision
5. Verification SHALL confirm that the Artifact Catalog Record preserves the relationships between successive baseline revisions
6. Verification SHALL confirm that the Artifact Catalog Record identifies the source and author of each tested baseline revision
7. Verification SHALL confirm that the Artifact Catalog Record identifies the approval status of each tested baseline revision
8. Verification SHALL confirm that the same approved Infrastructure Baseline can be selected for two or more Infrastructure Deployments
9. Verification SHALL confirm that reuse of an approved Infrastructure Baseline does not modify the approved baseline content
10. Verification SHALL confirm that a change to approved baseline content creates a separately identified revision
11. Verification SHALL confirm that each tested Infrastructure Deployment records the Artifact identifier and revision identifier of the selected Infrastructure Baseline
12. Verification SHALL confirm that each tested Infrastructure Deployment references the applicable Artifact Catalog Record
13. Verification SHALL confirm that Platform Specific Parameters remain distinguishable from the approved baseline content
14. Verification SHALL confirm that deployment-specific state remains distinguishable from the approved baseline content
15. Verification SHALL confirm that each tested Artifact Catalog Record preserves the applicable Provenance
16. Verification SHALL confirm that an authorized user can retrieve a prior baseline revision
17. Verification SHALL confirm that an authorized user can compare two baseline revisions
18. Verification SHALL confirm that the Artifact Catalog Record preserves Auditability and Traceability for baseline reuse and revision

Verification may include:

• Artifact Catalog Record inspection
• Artifact identifier inspection
• Revision identifier inspection
• Repository history inspection
• Baseline approval inspection
• Baseline content comparison
• Revision comparison
• Repeated deployment tests
• Cross-platform deployment tests
• Baseline selection tests
• Baseline reuse tests
• Baseline immutability tests
• Platform Specific Parameter inspection
• Deployment-specific state inspection
• Provenance inspection
• Deployment record inspection
• Prior revision retrieval tests
• End-to-end CI/CD Pipeline tests

The verification record SHALL identify:

1. The tested Infrastructure Baseline
2. The applicable Artifact Catalog Record
3. The Artifact identifier
4. The baseline revision identifier
5. The baseline source location
6. The baseline approval status
7. The baseline author
8. The preceding revision
9. The succeeding revision, when applicable
10. The tested Infrastructure Deployments
11. The Platform Specific Parameters
12. The deployment-specific state
13. The content comparison result
14. The revision comparison result
15. The applicable Provenance
16. The observed results
17. The generated Evidence

This requirement is realized by:

• OR-001 — Operational Roles
• OR-002 — Deployment Environments
• OR-003 — Classified and Unclassified Environments
• OR-004 — Concurrent Environment Management
• OR-005 — Distributed Environment Management
• FR-CFG-001 through FR-CFG-005
• FR-DEP-001 through FR-DEP-007
• FR-DSO-001 through FR-DSO-006
• FR-BAS-001 through FR-BAS-004
• MAINT-001 through MAINT-005
• DATA-001 through DATA-005
• KVP-003 — Improve deployment repeatability
• KVP-005 — Reduce configuration drift

KVP identifies a Key Value Proposition requirement.

This requirement also relates to:

• 5. Descriptions, Composition, and Baselines
• 7. Infrastructure and Deployment
• 10. Reproducibility, Provenance, and Traceability

The wiki Backlinks function provides the current list of pages that reference MO-005.

Incoming traceability should be derived dynamically from backlinks rather than maintained as a duplicate manual list.

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.

The Crucible Concept of Operations describes Baseline Composition as the use of versioned Image Layer and Infrastructure Baseline repositories alongside consumer source within a CI/CD Pipeline workspace.

The Phase 1 workflow:

• Selects the required baseline repositories
• Retrieves the identified baseline revisions
• Composes the selected baselines within the workspace
• Applies the selected Infrastructure Baseline
• Applies the required Platform Specific Parameters
• Records the source revision identifiers
• Performs Infrastructure Deployment
• Records the baseline identifier and revision used by the deployment
• Preserves deployment history and 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.

This operational model treats an Infrastructure Baseline as a reusable and versioned deployment input rather than a deployment-specific script or manually recreated configuration.

Phase 1 and subsequent phases

Not Assessed

Implementation status requires verification that approved Infrastructure Baselines are uniquely identified, version controlled, reusable across two or more deployments, described by Artifact Catalog Records, and traceable to the deployments that use them.

Draft

The source System Requirements Specification identifies Version 1.1 as a draft.

This requirement page should retain the stable requirement identifier MO-005.

Changes to the Statement SHALL preserve the approved intent of the source requirement.

Material changes should receive review and should update the related outbound traceability, verification criteria, baseline governance, acceptance criteria, and source records.

The Source Statement should preserve the original wording from the controlling System Requirements Specification.

Incoming traceability should use the wiki Backlinks function rather than a manually maintained list.

To reference this requirement Statement from another wiki page, insert:

{{section>dido:02-crusible:99-annexes:annex-c-requirements:01-mission-objectives:mo-005#Statement&noheader&nofooter&noeditbtn}}

Do not rename this page after an external citation unless a redirect or move plan is in place.