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

This is an old revision of the document!


MO-006

Crucible SHALL perform the applicable Operational Lifecycle activities for each Infrastructure Environment from initial Infrastructure Deployment through Retirement while preserving the applicable environment state, history, Provenance, Evidence, and Traceability.

The system SHALL support infrastructure lifecycle management from initial deployment through retirement.

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

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
  • Support is a weak verb that does not identify the behavior Crucible performs
  • Infrastructure lifecycle management does not identify the lifecycle activities, managed information, responsible components, or required outcomes
  • Initial deployment does not identify the event that begins the managed lifecycle
  • Retirement does not identify the required termination, archival, preservation, or resource disposition activities
  • The source statement does not identify which environment records must remain available throughout and after the lifecycle
  • The source statement does not define the acceptance criteria for lifecycle transitions
  • The source statement does not distinguish the lifecycle of an Infrastructure Environment from the lifecycle of a Baseline, Machine Image, or other Artifact

The normalized Statement replaces the weak verb with perform, identifies the managed Infrastructure Environment, bounds the lifecycle from initial deployment through retirement, and identifies the information that must remain preserved.

An Infrastructure Environment changes throughout its Operational Lifecycle.

After initial Infrastructure Deployment, an organization may need to:

  • Validate the deployed environment
  • Apply configuration changes
  • Apply security updates
  • Reassess compliance
  • Reconcile environment state
  • Recover failed operations
  • Restore an environment from a backup
  • Roll back an unsuccessful change
  • Replace or upgrade components
  • Preserve operational and compliance records
  • Retire the environment and dispose of its resources

Without controlled lifecycle management, an environment may diverge from its approved Baselines, lose Traceability, accumulate configuration drift, or retain resources after the environment is no longer authorized.

Crucible coordinates lifecycle activities through controlled Crucible Descriptions, versioned Baselines, recorded lifecycle transitions, validation activities, and preserved Evidence.

Each lifecycle transition should preserve the relationship among:

This requirement applies to:

  1. Verification SHALL confirm that each tested Infrastructure Environment has a unique identifier
  2. Verification SHALL confirm that the lifecycle record identifies the initial Infrastructure Deployment
  3. Verification SHALL confirm that each tested lifecycle transition has a unique identifier
  4. Verification SHALL confirm that each tested lifecycle transition identifies the applicable lifecycle activity
  5. Verification SHALL confirm that each tested lifecycle transition identifies the prior environment state
  6. Verification SHALL confirm that each tested lifecycle transition identifies the resulting environment state
  7. Verification SHALL confirm that each tested lifecycle transition identifies the applicable Crucible Description
  8. Verification SHALL confirm that each tested lifecycle transition identifies the applicable Baseline revisions
  9. Verification SHALL confirm that each tested lifecycle transition records the actor or automated process that initiated the action
  10. Verification SHALL confirm that each tested lifecycle transition records the execution result
  11. Verification SHALL confirm that each successful lifecycle transition satisfies the applicable acceptance criteria
  12. Verification SHALL confirm that each failed lifecycle transition preserves the last valid environment state or records the incomplete state
  13. Verification SHALL confirm that recovery or rollback restores the environment to a defined valid state
  14. Verification SHALL confirm that compliance reassessment records the applicable Compliance Findings
  15. Verification SHALL confirm that backup and restoration preserve the applicable environment configuration, state, and records
  16. Verification SHALL confirm that Retirement terminates or transfers the applicable infrastructure resources according to the approved retirement criteria
  17. Verification SHALL confirm that Retirement preserves the records required by the applicable retention policy
  18. Verification SHALL confirm that the lifecycle record preserves Provenance, Evidence, and Traceability from initial deployment through retirement

Verification may include:

  • Initial deployment tests
  • Environment validation tests
  • Configuration change tests
  • State reconciliation tests
  • Compliance reassessment tests
  • Upgrade tests
  • Upgrade rollback tests
  • Failed operation recovery tests
  • Backup tests
  • Restoration tests
  • Baseline revision transition tests
  • Machine Image replacement tests
  • Deployment history inspection
  • Lifecycle record inspection
  • Resource disposition inspection
  • Record retention inspection
  • Connected environment demonstrations
  • Disconnected environment demonstrations
  • Air-Gapped Environment demonstrations
  • End-to-end CI/CD Pipeline tests

The verification record SHALL identify:

  1. The environment identifier
  2. The applicable Operational Lifecycle activities
  3. The initial deployment record
  4. The tested lifecycle transitions
  5. The prior environment states
  6. The resulting environment states
  7. The applicable Crucible Descriptions
  8. The applicable Baseline revisions
  9. The initiating actors or automated processes
  10. The applicable acceptance criteria
  11. The execution results
  12. The recovery or rollback results
  13. The applicable backup and restoration records
  14. The applicable Compliance Findings
  15. The retirement record
  16. The resource disposition results
  17. The applicable retention policy
  18. The retained records
  19. The generated Evidence

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

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 Phase 1 as a CI/CD Pipeline integrated command-line utility that performs build, compliance, dependency capture, and deployment activities.

The Phase 1 workflow:

  • Retrieves controlled and versioned inputs
  • Composes selected Baselines
  • Builds and hardens Machine Images
  • Captures dependencies and Compliance Findings
  • Executes predeployment and postdeployment activities
  • Records deployment and compliance results
  • Tears down environments when they are no longer required

The ConOps primarily describes initial deployment and related Phase 1 execution. The broader Operational Lifecycle also includes modification, reassessment, recovery, restoration, upgrade, rollback, and Retirement activities required by this mission objective.

Phase 1 and subsequent phases

Not Assessed

Implementation status requires verification of the applicable Operational Lifecycle activities from initial Infrastructure Deployment through Retirement.

Draft

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


This requirement page should retain the stable requirement identifier `MO-006`.

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-006/start.1784145263.txt.gz
  • Last modified: 2026/07/15 12:54
  • by nick_dido