Managing Requirements Across a Classified/Unclassified Boundary in Defense Programs

A defense program covering both classified performance parameters and unclassified platform elements is not an edge case. It is the normal structure for most major weapons systems, C2 platforms, sensor integration programs, and autonomous vehicle developments that have both an operational capability (often classified) and a physical or interface layer (often unclassified or unclassified controlled). The engineering and security challenge is real and routinely underestimated during program setup.

The failure mode is predictable: a single requirements baseline is started in whatever tool the contractor has on hand, classification markings are applied paragraph-by-paragraph, and within eighteen months the program has an unmanageable document with mixed markings, a traceability matrix that can only be opened on classified networks, and an engineering team on the platform side that cannot access the requirements governing the interface they are building to. This is not a hypothetical. It is the status quo on many programs.

This article covers the structural approaches that avoid that failure mode, the organizational controls required to sustain them, and the tooling implications — including what can realistically be done on classified networks and what belongs on the unclassified side.

The Structural Foundation: Two Baselines, One Interface

The correct architecture is two separate, internally consistent requirements baselines, governed independently, connected by a formally controlled interface definition.

Baseline A (Classified): Contains classified performance parameters, operational thresholds, detection probabilities, engagement envelopes, classified algorithms, and any requirement whose content reveals operational capability. This baseline lives entirely on a classified network — typically a program-specific enclave at the appropriate classification level — and is managed under the program’s security classification guide (SCG).

Baseline B (Unclassified): Contains platform-level requirements, interface specifications, power and mechanical envelopes, environmental conditions, qualification requirements, and all requirements that define what the system must physically do without revealing why it must do it at that level of performance. This baseline can be worked by a broader team, shared with suppliers on DD Form 254 contracts, and managed on standard enterprise or cloud infrastructure.

The Interface Control Boundary: Between these two baselines sits a formal set of interface control documents (ICDs) or interface requirements specifications (IRSs) that are either unclassified or classified at the lowest level necessary to define the physical and logical connection. These documents are the bridge. They must be maintained with the same rigor as a hardware interface — any change on either side that affects the boundary requires a controlled change in the interface documents first.

This is not a novel architecture. It mirrors the physical security decomposition used in classified system design for decades. The problem is that requirements management practice often fails to apply the same discipline to the requirements artifacts that hardware engineers apply to the physical design.

Summary/Detail Decomposition: The Engineering Mechanism

The most technically useful approach for maintaining two baselines without losing engineering coherence is summary/detail decomposition applied deliberately at the classification boundary.

The concept: a requirement at the unclassified level states what the interface must support, without stating why or to what precise performance level the classified subsystem operates. The classified baseline contains the detail requirements — the specific values, thresholds, and modes — that allocate down from the classified system requirements to the subsystem performing the classified function.

Example (illustrative, not program-specific):

Unclassified IRS requirement: “The sensor interface shall support a data throughput of no less than [X] Gbps sustained under all defined environmental conditions per Section 4.”

Classified subsystem requirement (in classified baseline): “The sensor processing module shall achieve a detection probability of [classified value] against [classified target class] at [classified range] under [classified environmental condition], which drives a minimum interface throughput of [classified derived value], bounding the unclassified IRS requirement.”

The unclassified interface requirement is real and contractually binding. The classified requirement explains why that interface value was selected and provides the parent traceability. A supplier building to the unclassified IRS has everything they need. They do not have the classified rationale, and they do not need it.

This decomposition must be designed intentionally during the requirements architecture phase. It cannot be retrofitted cleanly. If you are starting a new program, the conversation about where the classification boundary sits in the requirements hierarchy belongs in the same meeting where you define your work breakdown structure and statement of work structure — not six months later when someone notices the interface spec has classification markings and the subcontractor cannot read it.

Organizational Controls Required

Structural separation of baselines only works if the organizational process enforces the boundary consistently. Three controls matter most:

1. Designated boundary owners. Every requirement in the classified baseline that drives a requirement in the unclassified baseline needs an identified engineer who holds access to both. This person — sometimes called a cross-domain lead or interface engineer — is responsible for ensuring that changes in the classified baseline are evaluated for their impact on the interface documents, and that changes to unclassified interface requirements are reviewed against classified performance to confirm they remain consistent. This role is often underresourced. It should not be.

2. Change control that crosses the boundary explicitly. Your configuration management process needs a change request category for changes that affect the interface boundary. A change that touches only the classified baseline, with no impact on the interface layer, follows a classified-only process. A change that modifies an interface value requires action in both baselines, even if the driver is classified. This dual-side change process needs to be documented in your systems engineering management plan (SEMP) and enforced by your CCB.

3. Access control aligned with need-to-know, not convenience. Engineers working the unclassified platform layer should not be routinely granted access to the classified baseline to “make it easier.” Need-to-know exists for a reason. The cross-domain leads exist precisely so that platform engineers do not need access to classified performance parameters to do their work. Granting broad access to simplify traceability is a security violation waiting to happen, and it undermines the boundary discipline the architecture depends on.

Tooling on Classified Networks: What You Can Actually Use

Commercial SaaS requirements management tools — including most modern cloud-based platforms — are not available on classified networks. This is a hard constraint, not a policy preference. Tools like Jama Connect and Flow Engineering operate as cloud SaaS and are appropriate for the unclassified baseline. They are not accessible from a SIPR or higher enclave without a government-approved cloud solution at the appropriate Impact Level, which most commercial vendors have not pursued for their full product.

For the classified baseline, the realistic options are:

IBM DOORS / DOORS Classic: Widely deployed on classified programs because it is a thick client that can be installed on classified LANs. Its age and UI are genuine liabilities — version control, branching, and modern traceability visualization are weak — but it works in an air-gapped environment and is well understood by cleared systems engineers across the defense industrial base. It remains the de facto standard for classified requirements management for practical reasons.

IBM DOORS Next (DOORS Next Generation): Can be deployed on-premise, which makes it viable on classified networks with appropriate infrastructure. More capable than DOORS Classic for linked data and traceability visualization, but the on-premise deployment burden is substantial and requires server infrastructure the program must own and maintain.

Polarion (on-premise): Siemens Polarion supports on-premise deployment and is used on some classified programs. It has stronger traceability and lifecycle integration capabilities than DOORS Classic, though the organizational investment to deploy and administer it is significant.

Codebeamer (on-premise): PTC’s Codebeamer also supports on-premise deployment and is increasingly used in defense programs, particularly those with software-heavy requirements. Its integration with PLM toolchains is an advantage in mixed hardware/software programs.

The common thread: if it runs on-premise with no external network dependency, it is a candidate for the classified network. If it requires a cloud connection for any core function, it is not.

Maintaining Traceability Across the Boundary

The hardest operational problem in this architecture is maintaining meaningful traceability when the two baselines cannot be directly linked in a single tool. Automated traceability across the boundary is not possible when the tools are physically separated. What replaces it is a governed manual process.

The cross-domain traceability registry is the practical solution. This is a document — formatted as a traceability matrix or a structured table — that records the relationship between classified requirement identifiers and the unclassified interface or platform requirement identifiers they drive. The registry itself is maintained at the classification level of the classified baseline. It is updated as part of every change process that touches either baseline, under the responsibility of the cross-domain lead.

The registry does not contain the content of classified requirements. It contains identifiers and relationship types: “Classified Req ID [XXX] allocates to Unclassified IRS Req ID [YYY] — interface throughput value.” An auditor with appropriate clearance can verify that every classified performance requirement has a traceable path to an interface specification. An unclassified engineer can see that IRS Req [YYY] exists and has a classified parent without seeing the parent’s content.

This is less elegant than a graph-linked model in a modern requirements tool. It is also the only approach that is security-compliant and actually works in a real classified program environment. The discipline required to maintain it accurately is organizational, not technological.

Managing the Unclassified Layer: Where Modern Tooling Earns Its Place

The unclassified requirements baseline — the platform requirements, interface specifications, supplier-facing requirements, and qualification requirements — is where modern requirements management tools provide genuine leverage.

Flow Engineering is well-suited for this layer. Its graph-based model means that requirements, interfaces, and verification artifacts are connected nodes rather than rows in a document, which directly supports the kind of interface-centric requirements architecture the cross-domain approach demands. When the unclassified baseline needs to trace from system-level interface requirements down through subsystem specs to verification methods, a connected graph model catches gaps and conflicts that a document-based tool does not.

The AI-assisted decomposition in Flow Engineering is particularly useful during the initial requirements architecture phase on the unclassified side — the period when the program is deciding exactly where the classification boundary sits and what the interface requirements must specify without revealing classified rationale. Decomposing interface requirements into verifiable, allocatable children is exactly the kind of structured but judgment-intensive work that AI assistance accelerates without replacing the engineer’s understanding of the security constraint.

Flow Engineering’s position as a cloud SaaS tool means it is the right choice for the unclassified tier and not an option for the classified tier. That is a deliberate product focus, not an architectural limitation — the company serves systems engineering teams working across commercial, dual-use, and unclassified defense programs where collaboration and modern tooling matter more than air-gap deployment.

Practical Starting Points for Programs Beginning This Work

If you are setting up a new program or correcting an existing one that has collapsed the boundary, the sequence that works:

  1. Define the SCG early. The security classification guide should be the first artifact that addresses where the performance parameters become classified. Every requirements architecture decision follows from it.

  2. Design the interface specification before writing either baseline. The ICD or IRS that sits at the boundary should be the first requirements document written, not derived later from two independently developed baselines.

  3. Name the cross-domain leads before baselining either document. The people responsible for boundary integrity need to be identified when requirements are being written, not brought in at CDR.

  4. Choose classified-side tooling based on your network environment, not preference. DOORS Classic is not ideal, but it works on a classified LAN. A modern tool that requires a cloud connection does not.

  5. Stand up the cross-domain traceability registry at program start, not as a corrective action. A registry that is populated from the beginning is manageable. A registry that must be reconstructed from two years of independent development is a program risk.

Honest Assessment

This architecture works. Programs that implement it with discipline — clean boundary definition, cross-domain leads with real authority, and a maintained traceability registry — can manage classified and unclassified requirements coherently without security compromise. Programs that treat the boundary as a documentation formality tend to find it at the worst possible moment: during a supplier audit, a CDR review, or a security assessment.

The tooling constraints on the classified side are real and will not improve quickly. Accepting that the classified baseline will live in DOORS or a similar on-premise tool, and investing in process discipline rather than waiting for better tooling, is the operationally sound choice. The unclassified side has no such constraint — it can and should be managed with the best available tooling. The engineering effort belongs at the boundary, not at either end of it.