dido:02-crusible:99-annexes:annex-c-requirements:01-mission-objectives:mo-005:start

This is an old revision of the document!


MO-005

Crucible SHALL maintain each Infrastructure Baseline as a uniquely identified, version-controlled Artifact that can be selected and applied to more than one Infrastructure Deployment 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 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 information, configuration, provenance, and lifecycle records that constitute the managed asset
  • 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 Infrastructure Baseline, and defines reuse as application to more than one Infrastructure Deployment without modifying the 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 with:

  • A stable identifier
  • A revision identifier
  • A revision history
  • Defined source content
  • 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

Version Control preserves the baseline history and supports comparison, rollback, audit, Reproducibility, and Traceability throughout the Operational Lifecycle.

  1. Verification SHALL confirm that each tested Infrastructure Baseline has a unique identifier
  2. Verification SHALL confirm that each tested Infrastructure Baseline has a revision identifier
  3. Verification SHALL confirm that the applicable Version Control system preserves the content associated with each baseline revision
  4. Verification SHALL confirm that the applicable Version Control system preserves the relationship between successive baseline revisions
  5. Verification SHALL confirm that the same approved Infrastructure Baseline can be selected for more than one Infrastructure Deployment
  6. Verification SHALL confirm that reuse of the approved Infrastructure Baseline does not modify the approved baseline content
  7. Verification SHALL confirm that changes to approved baseline content create a separately identified revision
  8. Verification SHALL confirm that each tested Infrastructure Deployment records the identifier and revision of the selected Infrastructure Baseline
  9. Verification SHALL confirm that platform specific parameters remain distinguishable from the approved baseline content
  10. Verification SHALL confirm that the baseline record preserves the applicable Provenance
  11. Verification SHALL confirm that an authorized user can retrieve a prior baseline revision
  12. Verification SHALL confirm that an authorized user can compare two baseline revisions
  13. Verification SHALL confirm that baseline reuse and revision records preserve Traceability

Verification may include:

  • Baseline identifier inspection
  • 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 CI/CD Pipeline tests

The verification record SHALL identify:

  1. The baseline identifier
  2. The baseline revision identifier
  3. The baseline source location
  4. The baseline approval status
  5. The preceding revision
  6. The succeeding revision, when applicable
  7. The platform specific parameters
  8. The content comparison result
  9. The revision comparison result
  10. The applicable Provenance
  11. The observed results
  12. The generated Evidence

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
  • Records the source revision identifiers
  • 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 multiple deployments, 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, 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.

Do not rename this page once it has been cited externally unless a redirect or move plan is in place.


© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.

  • dido/02-crusible/99-annexes/annex-c-requirements/01-mission-objectives/mo-005/start.1784145064.txt.gz
  • Last modified: 2026/07/15 12:51
  • by nick_dido