The Digital Engineering Mandate in the US Defense Industrial Base
When the DoD released its Digital Engineering Strategy in 2018, most contractors filed it alongside other policy documents that announce ambition without specifying consequence. That calculus has since changed. The strategy’s five pillars are now surfacing in source selection criteria, contract data requirements lists (CDRLs), and program office audits. For prime contractors, digital engineering is a competitive differentiator. For Tier 2 and Tier 3 suppliers, it is rapidly becoming a qualification threshold.
This article examines what the mandate actually requires, where the industrial base stands today, and what the tooling transition realistically looks like between now and the early 2030s.
What the Strategy Actually Requires
The 2018 DoD Digital Engineering Strategy organized its intent around five pillars: formalize digital engineering as a discipline, provide authoritative sources of truth, modernize the engineering ecosystem, invest in workforce, and implement digital engineering practices. Of these, the second — authoritative sources of truth — has the most direct operational impact on how defense programs manage requirements and systems data.
An authoritative source of truth (ASoT) in the DoD context is not simply a central document repository. It means a connected, version-controlled, queryable data environment where system models, requirements, analyses, interface definitions, and verification evidence are maintained as interrelated digital artifacts — not as isolated files. The distinction matters because the legacy approach (a requirements document linked by filename to a verification matrix in a separate spreadsheet) cannot support the traceability queries, change impact analyses, or programmatic audits that the strategy demands.
The complementary concept is the digital thread: a communication framework that links data across the program lifecycle, from early system concepts through design, manufacturing, test, and sustainment. A digital thread is not a tool. It is a data architecture that tools must support. What makes it operationally significant is that breaks in the thread — places where data is manually re-entered, converted between formats, or maintained in disconnected systems — are precisely where configuration drift, requirement misinterpretation, and late-cycle defects originate.
The third major construct is the digital twin, which receives substantial attention in program offices but is downstream of getting the thread right. A physics-based model that does not reflect the current authoritative baseline is not a digital twin — it is an expensive simulation. Getting the thread right is the prerequisite.
How Primes Are Responding
Large prime contractors — Lockheed Martin, Northrop Grumman, Raytheon, General Dynamics, Boeing Defense — have been investing in digital engineering infrastructure since before the strategy was published. The strategy did not initiate their programs; it accelerated them and gave them internal budget justification.
The approaches vary, but patterns are visible. Most large primes have standardized on SysML or its successor UAF (Unified Architecture Framework) for system modeling. They have invested heavily in model-based systems engineering (MBSE) tooling — primarily No Magic Cameo (now CATIA Magic), Rhapsody, or Capella — and are attempting to connect those models to requirements management platforms, PLM systems, and engineering simulation environments.
The integration challenge is real. A typical large defense program may have requirements managed in IBM DOORS or DOORS Next, system architecture modeled in Cameo, CAD data in NX or CATIA, simulation results in MATLAB or ModelCenter, and test evidence in a separate verification management system. Building a digital thread across that stack requires custom integration work, middleware platforms, or significant investment in platform vendors who claim to offer the connective tissue.
Where primes are making genuine progress is in new program starts. Programs that began after 2020 with digital engineering written into the program structure are showing cohesive digital thread architectures. Legacy programs — which represent the majority of current DoD contract value — are in various states of retrofit, and most program offices candidly acknowledge that full retrofit is not achievable within current budgets.
The other visible response is workforce investment. Digital engineering requires systems engineers who can build and interrogate models, not just write requirements documents. The shortage of that skill profile is acute, and primes are running internal training programs, partnering with universities, and competing aggressively for the limited pool of engineers with hands-on MBSE experience.
Where Supplier Readiness Gaps Exist
The honest assessment of the DIB below the prime level is uncomfortable. Tier 2 and Tier 3 suppliers — the companies producing subsystems, components, and software that primes integrate — are significantly behind, and the gap is not primarily about willingness.
The cost structure is the first problem. A mid-sized defense supplier with 200 engineers cannot absorb the licensing cost of enterprise MBSE platforms, the integration consulting required to connect them, and the training investment to build competency — all while maintaining schedule on existing contracts that do not yet require digital artifact delivery. The business case only works when contract requirements mandate it and when the additional cost is recoverable.
The second problem is requirements format mismatch. Primes are beginning to deliver decomposed requirements to suppliers in structured, model-derived formats. Many suppliers are not equipped to receive, parse, and respond to those artifacts in kind. They receive a model-derived requirements package and convert it manually back into a Word document because that is how their internal processes operate. The round-trip introduces exactly the kind of transcription error and traceability break the digital thread is designed to eliminate.
A 2024 survey by the National Defense Industrial Association found that fewer than 20% of Tier 2 and Tier 3 defense suppliers had implemented any form of MBSE tooling. Roughly 60% still managed requirements primarily in documents. These numbers have likely shifted modestly since publication, but the structural gap remains.
The third problem is data format standardization. Even when suppliers and primes are both using digital tools, they may not be using compatible data exchange formats. The AP233 standard for systems engineering data exchange exists, but adoption is inconsistent. ReSA (Requirements Interchange Format) and ReqIF are more widely supported but still not universally implemented. Programs that require model exchange frequently negotiate bespoke interface agreements, which is a manual and error-prone process.
The Realistic Timeline
Projecting full digital thread adoption across the DIB requires separating the new-start trajectory from the legacy retrofit trajectory, because they operate on fundamentally different timelines.
For new major defense acquisition programs initiated from 2023 forward, digital engineering requirements are increasingly standard in the Request for Proposal language. Source selection evaluations are beginning to score digital engineering maturity. By 2028, it is reasonable to expect that the majority of new program starts at the major defense acquisition program (MDAP) level will have functional digital threads maintained in connected toolchains from program initiation.
For legacy programs, the picture is more constrained. Programs that are deep into development or in production and sustainment will retrofit selectively. The most common pattern is establishing an authoritative source of truth for the configuration baseline going forward, without attempting to reconstruct the historical record in digital form. This is pragmatic but incomplete — the digital thread for a legacy program will have a defined start date rather than tracing back to system concept.
For the supplier base, 2028–2032 is the realistic window for meaningful penetration into Tier 2 and Tier 3. The forcing function will be primes requiring digital artifact delivery as a contract condition. As that requirement propagates down the supply chain, suppliers will either invest or lose contracts to competitors who have. The market mechanism is blunt but effective.
The wildcard is tooling cost and accessibility. If MBSE and digital thread tooling becomes substantially more affordable and easier to implement — a trend that cloud-native and AI-native tools are beginning to drive — the timeline compresses. If the tooling ecosystem remains dominated by expensive, complex enterprise platforms, the timeline extends.
The Tooling Ecosystem
The current tooling landscape for digital engineering in defense can be organized into three layers.
The system modeling layer is led by No Magic Cameo/CATIA Magic, IBM Rhapsody, Capella (open source), and Sparx Systems Enterprise Architect. These tools implement SysML and related modeling languages and are the primary environments where digital system architectures are built. They are powerful and deeply capable, but they require significant expertise to use effectively, and they are not designed as collaboration platforms for distributed teams.
The requirements management layer has historically been dominated by IBM DOORS, which has been the default for large defense programs for two decades. DOORS Next (the web-based successor) has improved the collaboration model but carries significant migration friction from classic DOORS. Jama Connect, Polarion, and Codebeamer are competing in this layer with more modern architectures and better integration stories. Each has real strengths: Jama’s review workflow is well-executed, Polarion’s PLM integration is strong, Codebeamer’s ALM-to-requirements bridge is genuinely useful.
The emerging layer — and where the most interesting development is happening — is AI-native tooling that addresses the most labor-intensive steps in digital thread construction: ingesting legacy requirements documents, decomposing high-level specifications into structured requirements, identifying traceability gaps, and flagging ambiguous or untestable requirement language.
This is where tools like Flow Engineering are finding genuine traction. Flow Engineering is built specifically for hardware and systems engineering teams managing complex, interdependent requirements and is architected around graph-based models rather than document hierarchies. That architectural choice matters in a digital engineering context because it natively represents the relational structure that ASoT demands — requirements, interfaces, verification methods, and design decisions as connected nodes, not as rows in a document. Its AI layer is not a chat interface bolted onto a legacy platform; it is integrated into the model structure, which means AI-generated traceability suggestions and gap analyses are grounded in the actual system model rather than operating on unstructured text.
For organizations at the beginning of a digital engineering transition — particularly Tier 2 suppliers working to meet prime-imposed requirements — a graph-native, AI-assisted platform offers a materially different on-ramp than trying to configure an enterprise PLM system or a legacy requirements tool.
The honest limitation to note: Flow Engineering is optimized for the requirements and traceability layers of the digital thread. Organizations that also need deep SysML modeling or full PLM integration will need to think carefully about where it fits in their overall stack, either as a primary platform with integrations to modeling tools or as a focused solution for requirements management within a broader toolchain.
Honest Assessment
The DoD Digital Engineering Strategy is real policy with real consequences, and the pressure it is creating on the DIB is not dissipating. The question for any defense contractor is not whether to invest in digital engineering capability, but when and how.
For large primes, the transition is underway and irreversible. The challenge is execution: integrating disparate legacy toolchains, building workforce competency, and extending digital thread requirements to suppliers in a way that does not simply shift the compliance burden without providing the tools to meet it.
For suppliers, the calculus is simpler and more urgent than many have acknowledged. The contracts that require digital artifact delivery are coming. Waiting for the requirement to appear in an RFP before investing in capability is a losing strategy — the lead time to implement and operationalize digital engineering tooling is not measured in weeks.
For the tooling ecosystem, the window for genuine differentiation is open. The programs being structured now will make platform decisions that persist for decades. AI-native tools that can demonstrably reduce the cost and time of digital thread construction — without requiring an army of MBSE consultants — are positioned to capture significant share of a market that is, at this moment, still in formation.
The digital thread is not a technology problem. It is a data discipline problem, and the tools that make that discipline achievable at realistic cost and staffing levels will determine how quickly the DIB’s long tail closes the gap.