1. Introduction [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.
====== 1. Introduction ======

[[dido:02-crusible:start|Go to Crucible]]

[[dido:99_annexes:annex-b-terms-and-definitions:c:crucible]] provides a controlled and reproducible approach for constructing, hardening, assessing, transferring, deploying, and maintaining software and [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_environment|Infrastructure Environments]]. It combines [[dido:99_annexes:annex-b-terms-and-definitions:d:declarative_description|Declarative Descriptions]], composable [[dido:99_annexes:annex-b-terms-and-definitions:b:baseline|Baselines]], [[dido:99_annexes:annex-b-terms-and-definitions:m:machine_image|Machine Images]], [[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]], deployment automation, and compliance automation into a coordinated operational lifecycle.

Constructing, hardening, assessing, transferring, deploying, and maintaining an operational system requires substantial engineering effort. These activities are necessary to deliver a secure, compliant, reproducible, and supportable system, but they usually do not implement the mission-specific [[dido:99_annexes:annex-b-terms-and-definitions:f:functional_requirement|Functional Requirements]] that justify the project.

A project that develops these capabilities independently must dedicate skilled personnel, time, and funding to infrastructure automation, image construction, dependency capture, compliance assessment, evidence generation, deployment, disconnected operation, and lifecycle maintenance. Implementing these capabilities correctly can consume many person-years. The work also creates an ongoing obligation because the project must maintain the resulting tools, configurations, integrations, security controls, and evidence throughout the [[dido:99_annexes:annex-b-terms-and-definitions:o:operational_lifecycle|Operational Lifecycle]] of the system.

These expenditures compete directly with the resources available to develop, test, and improve the project’s mission capabilities. Although each project could create its own solution, repeated project-specific implementations duplicate effort, increase inconsistency, and create separate maintenance burdens.

Organizations that support multiple products often compound this problem. Individual product teams frequently create and maintain separate approaches to image construction, infrastructure automation, compliance assessment, deployment, dependency management, and lifecycle support. These approaches can differ in tools, conventions, interfaces, evidence formats, and operating procedures, even when the products must satisfy similar technical and governance obligations.

This inconsistency limits reuse across the organization. Software, Baselines, automation, evidence, and operational practices developed for one product can be difficult to apply to another. Personnel must learn different toolchains and procedures as they move between projects, reducing personnel mobility and making specialized skills harder to reuse. Organizations must therefore maintain additional teams, duplicate expertise, and spend more time integrating or reconciling product-specific solutions.

A centrally maintained Crucible capability provides a common operational foundation across products. Shared tooling, controlled terminology, reusable Baselines, consistent interfaces, and common lifecycle practices allow organizations to reuse both software and expertise. Product teams can move personnel between efforts more readily, reduce duplicated maintenance, and apply improvements across multiple products rather than implementing the same change independently for each system.

[[dido:99_annexes:annex-b-terms-and-definitions:c:crucible]] provides these shared capabilities as a controlled foundation. Projects can use Crucible rather than independently solving the same infrastructure, deployment, compliance, transfer, and lifecycle problems. This allows project teams to concentrate a greater share of their resources on the functionality that distinguishes the system and delivers its mission value.

Crucible supports operations in [[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]]. It preserves [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceability]], [[dido:99_annexes:annex-b-terms-and-definitions:p:provenance|Provenance]], and [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]] across lifecycle stages and transfer boundaries.

Crucible supports [[dido:99_annexes:annex-b-terms-and-definitions:a:accredited_software_factory|Accredited Software Factory]] objectives, 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 governing criteria, assessment results, and supporting Evidence.

===== Contents =====

{{indexmenu>dido:02-crusible:01-introduction#1|js navbar nocookie maxjs#2 id#crucible_introduction_toc_nav}}

----

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