MO-005 — Reusable and Version-Controlled Infrastructure Baselines [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.
====== MO-005 — Reusable and Version-Controlled Infrastructure Baselines ======

[[dido:02-crusible:99-annexes:annex-c-requirements:01-mission-objectives:start|Go to Mission Objectives]]

===== Original Requirement =====

> //The system SHALL establish infrastructure as a reusable and version-controlled asset.//[[dido:02-crusible:99-annexes:annex-b:cr-001|[C1]]]

===== Assessment of Original Requirement =====

The Original Requirement preserves the approved mission objective but does not express independently testable normative statements.

The following Specification Discipline and Authoring findings apply:

  * **The system** does not use the defined system name [[dido:99_annexes:annex-b-terms-and-definitions:c:crucible|Crucible]]
  * **Establish** is a weak verb that does not identify an observable behavior performed by Crucible
  * **Infrastructure** does not identify the managed subject as an [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_baseline|Infrastructure Baseline]]
  * **Asset** does not use the defined concept [[dido:99_annexes:annex-b-terms-and-definitions:a:artifact|Artifact]]
  * **Reusable** does not identify the required reuse behavior
  * **Version-controlled** combines several independently testable behaviors without identifying them separately

The Original Requirement does not identify:

  * How Crucible manages an Infrastructure Baseline as an Artifact
  * How Crucible uniquely identifies each Infrastructure Baseline
  * How Crucible distinguishes Infrastructure Baseline revisions
  * How an approved Infrastructure Baseline revision is selected for an [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_deployment|Infrastructure Deployment]]
  * The minimum number of Infrastructure Deployments required to demonstrate reuse
  * Whether approved Infrastructure Baseline content may change during reuse
  * How each Infrastructure Deployment identifies the Infrastructure Baseline revision used

The Original Requirement therefore requires:

  * Replacement of **the system** with the defined system name [[dido:99_annexes:annex-b-terms-and-definitions:c:crucible|Crucible]]
  * Replacement of **establish** with observable Crucible behavior
  * Identification of the managed subject as an Infrastructure Baseline
  * Management of each Infrastructure Baseline as an Artifact
  * Unique identification of each Infrastructure Baseline
  * Identification and preservation of Infrastructure Baseline revisions
  * Selection of an approved Infrastructure Baseline revision for Infrastructure Deployment
  * Reuse of an Infrastructure Baseline revision across multiple Infrastructure Deployments
  * Preservation of approved Infrastructure Baseline content during reuse
  * Traceability from each Infrastructure Deployment to the Infrastructure Baseline revision used
  * Confirmation that the derived requirements collectively preserve the complete intent of MO-005

The decomposition preserves ''MO-005'' as the stable parent requirement identifier. Each proposed replacement requirement receives a lettered identifier and a separate leaf requirement page.

===== Proposed Statements =====

The Original Requirement is decomposed into the following proposed replacement requirements:

{{indexmenu>dido:02-crusible:99-annexes:annex-c-requirements:01-mission-objectives:mo-005#1|js navbar nocookie maxjs#1 id#crucible_mo_005_requirements_nav}}

===== Requirement Status =====

<todo>Review and approve the proposed decomposition of MO-005 into independently testable Infrastructure Baseline management, identification, revision-control, selection, reuse, preservation, and Traceability requirements.</todo>

<todo>Determine whether MO-005a through MO-005g collectively supersede MO-005.</todo>

<todo>If MO-005a through MO-005g are accepted as the complete replacement for MO-005, mark MO-005 as superseded and preserve this page as the parent Traceability record.</todo>

----
===== Issues =====

The following unresolved issues affect the decomposition of MO-005:

<todo>Define the Artifact-management requirements that apply to an Infrastructure Baseline.</todo>

<todo>Define the identifier assigned to each Infrastructure Baseline and the authority responsible for assigning it.</todo>

<todo>Define the revision identifier, revision sequence, and change-control rules for Infrastructure Baselines.</todo>

<todo>Define the approval authority and approval status required before an Infrastructure Baseline revision may be selected for Infrastructure Deployment.</todo>

<todo>Define the minimum number of Infrastructure Deployments required to demonstrate Infrastructure Baseline reuse.</todo>

<todo>Define whether reuse requires identical Controlled Inputs other than deployment-specific parameters.</todo>

<todo>Define the behavior required when a change to an approved Infrastructure Baseline is necessary.</todo>

<todo>Define the Traceability record that associates each Infrastructure Deployment with the Infrastructure Baseline identifier and revision used.</todo>

<todo>Determine whether MO-005a through MO-005g provide complete coverage of the approved intent of MO-005.</todo>

----
===== Notes for Editors =====

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

This page is a non-leaf requirement page and retains a trailing '':start'' in its namespace.

The child requirements are leaf requirement pages and omit a trailing '':start'' from their namespaces.

The explicit child-page links should remain while the proposed decomposition is being developed. After the child pages have been created and finalized, the explicit links may be removed because the ''indexmenu'' displays the child requirement pages contained within the MO-005 namespace.

This page preserves:

  * The Original Requirement
  * The assessment of the Original Requirement
  * The reason for decomposition
  * [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceability]] to the proposed replacement requirements
  * The unresolved cross-cutting issues affecting the decomposition
  * The supersession decision

The derived requirements should distinguish:

  * Management of an Infrastructure Baseline as an Artifact
  * Identification of an Infrastructure Baseline
  * Identification and control of Infrastructure Baseline revisions
  * Approval and selection of an Infrastructure Baseline revision
  * Reuse of an Infrastructure Baseline revision
  * Preservation of approved Infrastructure Baseline content
  * Traceability from an Infrastructure Deployment to the Infrastructure Baseline revision used

Reuse does not mean modification of an approved Infrastructure Baseline revision. A required change should produce a new controlled revision rather than alter the approved revision already used by prior Infrastructure Deployments.

Infrastructure Baseline identification and Infrastructure Baseline revision identification are separate concerns. The baseline identifier identifies the managed baseline, while the revision identifier distinguishes one controlled state of that baseline from another.

The Original Requirement should not be marked as superseded until the requirement owner:

  * Approves the proposed decomposition
  * Approves the child requirements
  * Defines the Infrastructure Baseline identification and revision-control rules
  * Defines the approval and selection process
  * Defines the minimum reuse condition
  * Defines the preservation and change-control rules
  * Defines the required Infrastructure Deployment Traceability record
  * Confirms that the child requirements collectively preserve the complete approved intent of MO-005
  * Confirms that no additional child requirements are required

After supersession, this page should remain as the parent Traceability record and should continue to preserve the Original Requirement and its assessment.

Material changes to the decomposition should update the child requirements, Requirement Status, Issues, and Traceability records.

----

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