Table of Contents

OR-003 — Classified and Unclassified Environments

Go to Operational Requirements

Original Requirement

The system SHALL support classified and unclassified deployment environments.[C1]

Assessment of Original Requirement

The Original Requirement preserves the approved operational intent but does not express independently testable normative statements.

The following Specification Discipline and Authoring findings apply:

The previously normalized Statement also combined:

These obligations can pass or fail independently.

For example:

The Original Requirement therefore requires decomposition into independently identifiable normative requirements.

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

The decomposition separates:

Proposed Statements

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

Requirement Status

Review and approve the proposed decomposition of OR-003 into independently testable Classified Environment operations, Unclassified Environment operations, Security Domain enforcement, Information Handling Rule enforcement, Cross-Domain Transfer control, and Security Domain access-control requirements.

Determine whether OR-003a through OR-003f collectively preserve the complete approved intent of OR-003.

Determine whether OR-003a through OR-003f collectively supersede OR-003.

If the proposed child requirements are accepted as the complete replacement for OR-003, mark OR-003 as superseded and preserve this page as the parent Traceability record.


Issues

The following unresolved issues affect the decomposition of OR-003:

Define the Operational Lifecycle activities that Crucible must execute within Classified Environments.

Define the Operational Lifecycle activities that Crucible must execute within Unclassified Environments.

Identify the Security Classifications that each supported Classified Environment is authorized to handle.

Identify the Classification Authority governing each Security Classification used by Crucible.

Define the Security Domain boundaries governing each Classified Environment and Unclassified Environment.

Define the resources, information, operations, users, and processes authorized within each Security Domain.

Define the Information Handling Rules governing each Security Classification and handling designation.

Define how Crucible associates Information Handling Rules with information and information-bearing Artifacts.

Define the behavior required when information lacks a Security Classification or handling designation.

Define the Cross-Domain Transfer mechanisms authorized between supported Security Domains.

Define the authorization required for each Cross-Domain Transfer.

Define the validation, integrity, inspection, and destination-acceptance requirements for Cross-Domain Transfers.

Define the behavior required when information is not authorized for the destination Security Domain.

Define the identity, role, authorization, and need-to-know information used to control access within a Security Domain.

Define the behavior required when an automated process lacks authorization for a requested operation, resource, or information object.

Determine whether OR-003a through OR-003f provide complete coverage of the approved intent of OR-003.


Notes for Editors

This page should retain the stable parent requirement identifier OR-003.

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 OR-003 namespace.

This page preserves:

The derived requirements should distinguish:

The proposed child Statements should retain the following intent:

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

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.


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