Digital Engineering in the US Defense Industrial Base: Policy vs. Reality

The Pentagon’s digital engineering ambitions are not new. The DoD Digital Engineering Strategy, released in 2018, set a clear directional mandate: move from document-centric engineering to an authoritative model-based approach, establish a digital thread from requirements through sustainment, and use data — not paper — as the primary engineering artifact. Eight years later, the question is not whether this transition is happening. It is. The question is how deep it actually runs, and who it’s leaving behind.

The honest answer: progress is uneven in ways that matter operationally. The gap between where policy says the industrial base should be and where most of it actually operates is large enough to create real program risk — and that gap is not distributed evenly.

What Policy Actually Requires Now

The 2018 Digital Engineering Strategy established the framework, but implementation pressure has intensified through a sequence of downstream directives. The CDAO (Chief Digital and AI Office) has issued guidance tying digital engineering maturity to program milestone decisions. The USD(R&E) has incorporated digital engineering readiness into Technology Readiness Level assessments. Program Executive Offices — particularly in aviation, shipbuilding, and missile systems — have begun writing model-based deliverables directly into contract requirements.

The specific mechanisms forcing real adoption are worth examining closely, because vague policy has been replaced by concrete contractual language.

RFP language has shifted. Where acquisition documents once asked for a Systems Engineering Management Plan describing how a contractor would do systems engineering, current RFPs at major programs increasingly require evidence of a functioning digital thread: model artifacts in specified formats (SysML, Cameo exports, STEP), metadata schemas, and access protocols for government review of authoritative sources. Some program offices are specifying that government engineers will have read access to contractor model environments — not just receive static exports.

CDRL structures are changing. Contract Data Requirements Lists, historically the mechanism for specifying deliverable documents, are being modified to include model-based deliverables alongside or in place of traditional documents. A System Requirements Specification (SRS) delivered as a SysML model package rather than a Word document is now contractually required on multiple active programs. This is significant: CDRLs have legal and payment implications. When a CDRL requires a model artifact, the contractor cannot substitute a document and claim compliance.

Audit practices are catching up. The Defense Contract Audit Agency (DCAA) and Defense Contract Management Agency (DCMA) have begun incorporating digital engineering readiness into their review criteria. Earned Value Management reviews at some programs now include questions about model currency — whether the authoritative model reflects the current design state. This is still inconsistent across programs, but the trajectory is clear: auditors are being trained to ask questions that only make sense if you take model-authority seriously.

Where Prime Contractors Actually Are

The primes — Lockheed Martin, Raytheon (RTX), Northrop Grumman, General Dynamics, L3Harris, and their immediate peers — have made genuine investment in digital engineering capability. This is not marketing. They have hired MBSE practitioners, stood up tool environments (primarily Cameo/MagicDraw, IBM DOORS Next, and Dassault’s 3DEXPERIENCE), and have programs where model artifacts are the design authority.

But “genuine investment” and “model-authoritative operation” are not the same thing.

Most large prime contractors are running what practitioners honestly describe as hybrid environments. A design exists in a SysML model. The same design exists in a Word document, because that’s what the program’s legacy review process expects, what subcontractors can receive, and what engineers trained before 2015 are comfortable working with. Both artifacts exist. Neither is definitively authoritative. When they diverge — and they do — the reconciliation is manual, slow, and error-prone.

This is not a failure of intent. It reflects real constraints: legacy programs running on existing review structures that were not designed for model-based workflows, workforce trained on document-based methods who require significant retraining, and subcontract relationships where digital artifact exchange is not yet technically feasible at scale.

The most mature implementations at the prime level are on newer programs — particularly those started after 2020, where program offices wrote digital engineering requirements into the contract from the beginning rather than trying to retrofit them. NGAD, the Next Generation Interceptor, and several classified programs have reportedly achieved something closer to genuine model-authority on specific domains. But these are not representative of the broader portfolio.

The Supply Chain Gap Is the Real Problem

If the prime contractor situation is “progress with significant caveats,” the small and mid-tier supplier situation is more accurately described as a capability cliff.

The defense industrial base includes thousands of companies — component manufacturers, subsystem integrators, specialized test providers, software developers — that work as subcontractors to the primes. Many of them have between 50 and 500 engineers. Most do not have a dedicated MBSE capability. Many are still operating on requirements delivered as PDFs or Word documents, tracking changes in spreadsheets, and producing deliverables that meet the form of what primes request rather than the functional intent.

This is not ignorance. It is economics and workforce reality. Implementing a serious MBSE toolchain requires software licenses that cost tens of thousands of dollars per seat for tools like IBM DOORS Next or Cameo, plus training investment, plus at least one person with genuine expertise to establish and maintain the environment. For a 200-person aerospace supplier with 8% program margins, that is a material capital decision — one that is hard to justify if the prime contractor’s actual interface to them is still a requirements document in a shared folder.

The policy response has been to push digital engineering requirements down into subcontracts, which primes are increasingly doing. This creates compliance pressure without capability development. Suppliers respond by purchasing tools they do not yet know how to use effectively, generating model artifacts that satisfy the letter of a CDRL requirement but do not constitute a functioning digital thread. A SysML model that is not maintained, not connected to design and test artifacts, and not used by engineers in daily work is not digital engineering — it is digital engineering theater.

The Small Business Innovation Research (SBIR) program has funded some relevant capability development, and the Manufacturing USA institutes have run digital engineering pilots. But the gap between pilot programs and widespread industrial base capability remains large. The DoD’s own industrial base assessments have flagged supplier digital engineering readiness as a systemic risk — not a fringe concern.

What Would Close the Gap

Several things are actually working, in places where they have been tried seriously.

Program-level technical assistance. A handful of program offices have funded direct technical assistance to key suppliers — not just issuing requirements, but sending government or prime technical staff to help suppliers stand up working environments. This is resource-intensive but produces real capability rather than compliance theater.

Tiered requirements. Some contracts are now specifying different digital engineering requirements at different supply chain tiers, recognizing that a first-tier subsystem integrator and a third-tier fastener manufacturer have fundamentally different appropriate roles in a digital thread. This reduces the pressure on suppliers to implement capabilities they genuinely do not need while preserving the integrity of the thread where it matters.

Interface standardization. Where programs have specified exactly what digital artifacts they will exchange at each interface — not just “provide model artifacts” but “provide a SysML IBD in Cameo XML format with these metadata fields populated” — supplier compliance rates improve significantly, because the requirement is concrete enough to actually meet.

Where AI-Assisted Tools Fit

The workforce constraint underlying all of this is real. The US does not have enough engineers trained in model-based systems engineering to implement the DoD’s digital engineering vision at the scale and pace the policy timeline implies. This is where AI-assisted systems engineering tools have a practical role that is neither hype nor irrelevant.

The most immediate value is in the translation and traceability work that consumes enormous engineering time in any transition to model-based workflows. Converting legacy document-based requirements into structured, traceable model artifacts is tedious, error-prone, and expensive when done manually. Maintaining traceability as requirements change — ensuring that a change to a system requirement propagates visibly through subsystem, component, and test requirements — is the work that makes a digital thread genuinely useful rather than a compliance artifact.

Tools like Flow Engineering are designed specifically for this environment: graph-based requirements management with AI assistance for traceability, impact analysis, and requirements quality checking. For an engineering team that is transitioning from document-centric to model-centric workflows, the practical value is in reducing the labor required to build and maintain a living requirements model — and in making the traceability visible enough that engineers actually use it rather than treating it as an administrative burden.

Flow Engineering’s focus on hardware and systems engineering workflows, rather than attempting to be a general-purpose requirements tool, makes it relevant to defense programs specifically. The platform handles the kind of multi-level requirements hierarchies and interface control document relationships that are endemic to defense systems work, with AI-assisted analysis that flags gaps and conflicts rather than waiting for a human reviewer to find them during a design review.

The broader category of AI-assisted systems engineering tools — including AI-augmented features being added to established platforms like IBM DOORS Next and Jama Connect — matters for the supplier readiness problem in particular. If a 150-person aerospace supplier can implement a capable requirements traceability environment with lower overhead than a full enterprise MBSE suite requires, the economics of supplier digital engineering compliance change. The tool cost and training burden have been real barriers; tools designed for faster time-to-value without requiring dedicated MBSE expertise to operate are genuinely addressing a real constraint.

The caution is that AI assistance does not substitute for an engineering methodology. A tool that generates traceability links automatically can produce confident-looking but incorrect relationships if the underlying requirements are ambiguous. The discipline of writing requirements that are specific, verifiable, and correctly allocated remains a human judgment problem — AI tools accelerate the work but do not replace the expertise.

Honest Assessment

The DoD’s digital engineering push is the most consequential structural change to defense acquisition engineering practice in a generation. It is not reversing. The policy architecture — RFP requirements, CDRL specifications, audit criteria — is now robust enough that contractors cannot reasonably ignore it, and the enforcement machinery is slowly but visibly activating.

Prime contractors are further along than skeptics acknowledge but further from genuine model-authority than their marketing suggests. The hybrid document-and-model reality that most programs operate in is an improvement over pure document-centric work, but it does not yet deliver the digital thread benefits that justify the investment at scale.

The supplier readiness problem is the most acute near-term risk to the policy succeeding on its own terms. Digital engineering requirements propagating down supply chains faster than capability develops creates compliance-without-substance — which wastes money, creates audit liability, and does not improve engineering outcomes.

AI-assisted tools represent a real accelerant, particularly for the requirements traceability work that is simultaneously most labor-intensive and most foundational to a working digital thread. But they are accelerants for organizations that are executing a real transition, not substitutes for one.

The defense industrial base is moving. The question is whether the policy timeline and the capability development reality converge before the gap between them produces program failures significant enough to force a reassessment.