2.2 Mission and Expected Outcomes [Dido Solutions, Inc Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 2.2 Mission and Expected Outcomes ======

[[dido:02-crusible:02-operational-purpose-and-mission:start|Go to 2. Operational Need and Mission]]

The mission of [[dido:99_annexes:annex-b-terms-and-definitions:c:crucible|Crucible]] is to provide a reusable and centrally maintained operational foundation for constructing, hardening, assessing, transferring, deploying, reproducing, and maintaining software and [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_environment|Infrastructure Environments]].

Crucible fulfills this mission by coordinating:

  * [[dido:99_annexes:annex-b-terms-and-definitions:d:declarative_description|Declarative Descriptions]] of intended environments and lifecycle activities
  * Selection and composition of version-controlled [[dido:99_annexes:annex-b-terms-and-definitions:b:baseline|Baselines]]
  * Construction and maintenance of [[dido:99_annexes:annex-b-terms-and-definitions:m:machine_image|Machine Images]]
  * Definition and deployment of infrastructure through [[dido:99_annexes:annex-b-terms-and-definitions:i:iac|Infrastructure as Code (IaC)]]
  * [[dido:99_annexes:annex-b-terms-and-definitions:d:dependency_capture|Dependency Capture]] and preservation
  * [[dido:99_annexes:annex-b-terms-and-definitions:c:compliance_assessment|Compliance Assessment]]
  * Controlled transfer across connectivity and security boundaries
  * Preservation of [[dido:99_annexes:annex-b-terms-and-definitions:p:provenance|Provenance]], [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceability]], and [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]]

Crucible separates provider-independent intent from provider-specific implementation through [[dido:99_annexes:annex-b-terms-and-definitions:p:provider_abstraction|Provider Abstraction]]. This separation allows projects to apply common lifecycle concepts and controls while selecting the providers, platforms, tools, and extensions appropriate to their operational needs.

Crucible supports operations across [[dido:99_annexes:annex-b-terms-and-definitions:c:connected_environment|Connected Environments]], [[dido:99_annexes:annex-b-terms-and-definitions:d:disconnected_environment|Disconnected Environments]], and [[dido:99_annexes:annex-b-terms-and-definitions:a:air-gapped_environment|Air-Gapped Environments]]. The operational approach preserves the information needed to identify inputs, reproduce results, assess compliance, transfer required artifacts, and verify the relationship between an intended environment and the environment produced.

The expected operational outcomes include:

  * Reduced duplication of infrastructure, image-building, dependency, compliance, transfer, and deployment capabilities across projects
  * Increased reuse of Baselines, automation, provider integrations, assessment content, and operational practices
  * More consistent lifecycle activities across products and programs
  * Improved personnel mobility through common concepts, interfaces, tools, and procedures
  * Reproducible environments constructed from identified and version-controlled inputs
  * Portable provider-independent intent that can be realized through different provider-specific implementations
  * Controlled movement of dependencies, artifacts, assessment results, and Evidence across operational boundaries
  * Improved Traceability among operational intent, requirements, configuration, construction, deployment, assessment, and resulting Evidence
  * Greater [[dido:99_annexes:annex-b-terms-and-definitions:a:auditability|Auditability]] of lifecycle activities and operational results
  * Reduced maintenance effort when shared corrections, security changes, compliance updates, and operational improvements apply across multiple projects

These outcomes describe the operational effects sought through Crucible. They do not create an independent set of requirements.

The controlling Mission Objectives reside in [[dido:02-crusible:99-annexes:annex-c-requirements:01-mission-objectives:start|Annex C.1: Mission Objectives]]. The controlling Operational Requirements reside in [[dido:02-crusible:99-annexes:annex-c-requirements:02-operational-requirements:start|Annex C.2: Operational Requirements]].

Crucible supports the technical and evidentiary objectives associated with an [[dido:99_annexes:annex-b-terms-and-definitions:a:accredited_software_factory|Accredited Software Factory]], but Crucible does not grant [[dido:99_annexes:annex-b-terms-and-definitions:a:accreditation|Accreditation]], [[dido:99_annexes:annex-b-terms-and-definitions:o:operational_approval|Operational Approval]], or an [[dido:99_annexes:annex-b-terms-and-definitions:a:ato|Authority to Operate (ATO)]]. The responsible governance, assessment, and authorizing authorities make those determinations using the applicable criteria, assessment results, and supporting Evidence.

----

<WRAP centeralign>
© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.
</WRAP>