Digital Twins in Defense: How the Pentagon’s Digital Engineering Strategy Is Reshaping Acquisition

When the Office of the Secretary of Defense published its Digital Engineering Strategy in 2018, the reaction inside the defense industrial base ranged from cautious optimism to quiet skepticism. Eight years later, that strategy has graduated from a policy aspiration to a contract enforcement mechanism. Major RFPs now require MBSE deliverables. Source selection criteria score digital engineering maturity. And the phrase “authoritative source of truth” appears in program office briefs with enough frequency that it has become either a genuine architectural commitment or the most overused phrase in defense acquisition, depending on which contractor you ask.

The gap between the phrase and the practice is exactly what is worth examining.

What a Defense Digital Twin Actually Is

The popular shorthand — “a digital twin is a 3D model of the thing” — is not wrong, exactly. It just describes about five percent of what a defense program means when it mandates a digital twin.

In a defense acquisition context, a digital twin is a connected, authoritative digital representation of a system that spans its entire lifecycle. That means requirements and their rationale. Functional architecture. Physical architecture. Interface definitions. Manufacturing process data — tolerances, material certifications, build sequences. Verification and validation records tied to specific requirements. And, for fielded systems, operational performance data flowing back to update the model.

The word “authoritative” carries significant weight here. It means that when a requirement changes, that change propagates — traceable and visible — to every downstream artifact that depends on it. Design models, test procedures, manufacturing work instructions, training materials. The change does not live only in a Word document or an engineering change proposal sitting in a document management system. It lives in the model, and the model is the record.

The phrase “digital thread” describes the connective tissue: the continuous, traceable linkage across disciplines and lifecycle phases that makes the twin useful rather than merely decorative. A program can have sophisticated 3D models and robust simulation environments and still have no digital thread, because the models do not talk to the requirements database, the requirements database does not talk to the V&V records, and none of them talk to the supply chain. That condition describes most defense programs operating today.

Where the DoD Has Actually Piloted This

Three domain areas have the most instructive pilot programs.

Naval shipbuilding. The Navy’s Digital Twin Initiative, running across both the DDG-51 Flight III program and elements of the Columbia-class submarine, has been the highest-profile application. The shipbuilding environment is particularly challenging — ships are enormously complex, built over years by fragmented supply chains, and operate for decades. The Navy has invested heavily in 3D product models at the shipyard level, and both Huntington Ingalls Industries and General Dynamics Bath Iron Works have made significant MBSE investments. The concrete wins have come primarily in change management: when a design change is proposed, the digital model makes it possible to assess interference impacts across systems faster than the legacy drawing-and-markup process. The gap that persists is the requirements-to-design linkage. The 3D model exists. The requirements database exists. The live traceability between them is largely manual and frequently stale.

Fixed-wing aircraft. The F-35 program is often cited as a digital engineering precursor — it was designed with a heavy reliance on digital product definition — but the more instructive current example is the Next Generation Air Dominance (NGAD) program and the T-7A Red Hawk trainer. The T-7A, developed by Boeing using a model-based approach, demonstrated a 75 percent reduction in engineering drawing hours and an 80 percent reduction in manufacturing defects during assembly, according to Boeing’s published program data. The NGAD program, whatever its current budget status, was structured from inception to require MBSE as a core engineering method, not a supplemental activity. The lesson from both programs is that digital engineering produces the most measurable gains when it is designed in from the requirements phase — not retrofitted onto a program already in development.

Ground vehicles. The Army’s Next Generation Combat Vehicle family and the Optionally Manned Fighting Vehicle (OMFV) program have included explicit MBSE requirements in source selection. The ground vehicle domain is notable because the systems integrators — General Dynamics Land Systems, BAE Systems, Rheinmetall — must manage not just mechanical and electrical complexity but increasingly software-intensive systems where requirements volatility is high. Here the digital twin concept intersects directly with software systems engineering: keeping requirements, software architecture, hardware interfaces, and operational scenarios synchronized across a development cycle that may stretch a decade.

The Tooling Reality: What Primes Are Actually Using

Prime contractors’ current tooling environments tell a more complicated story than the program office briefs suggest.

The dominant MBSE modeling tool remains Cameo (now No Magic / Dassault Systèmes), with Rhapsody and Capella occupying significant shares of the aerospace and defense market. On the requirements side, IBM DOORS and DOORS Next remain deeply entrenched — particularly on legacy programs where DOORS has been the contractual requirements repository for fifteen or twenty years. Jama Connect has gained ground on newer program starts, particularly where the program office has been willing to move away from the DOORS ecosystem. Polarion is common in integrated software-hardware environments where ALM and requirements management need to coexist in a single tool.

The integration between these tools is where the digital thread frays. A program might use Cameo for system modeling, DOORS Next for requirements, Teamcenter or Windchill for product lifecycle management, and a separate test management platform for V&V. Each tool has its own data model, its own change management workflow, and its own user community. Integration exists — there are connectors, APIs, and ReqIF exchange formats — but maintaining synchronized, bidirectional traceability across these tools in a live program environment requires dedicated toolchain engineering effort that most programs underinvest in.

The practical consequence is that the “authoritative source of truth” in many programs is authoritative in name only. The model and the requirements database are frequently out of sync. Verification status in the test management system does not automatically reflect design changes in the product model. Engineers work around the gaps with spreadsheets and status meetings, which is precisely the behavior the digital engineering strategy was designed to eliminate.

Requirements Management as the Critical Bottleneck

If you had to identify the single process area where the gap between the digital engineering vision and current practice is widest, it is requirements management — specifically, the ability to maintain live, bidirectional traceability between requirements and everything downstream.

The legacy tooling was not designed for the way modern defense systems are specified. Requirements in a complex defense program are not a static list. They are a living network: customer requirements decompose to system requirements, which allocate to subsystems, which flow to components and software modules. Each node in that network has a rationale, a verification method, a status, and a set of dependencies on other requirements. When the operational concept changes — and it will — the ability to trace that change to its downstream implications quickly determines whether the program can respond in weeks or months.

Document-based requirements management tools handle this network poorly. Sections and subsections in a Word document or a DOORS module are not the same as nodes in a graph. Finding all the downstream impacts of a proposed change requires manual analysis — an experienced systems engineer reading through linked modules — rather than a query.

This is where newer, graph-native requirements management approaches offer a structural advantage over legacy document-based tools. Tools built on a graph data model can represent the full requirements network — including parent-child relationships, allocation links, verification closures, and cross-program dependencies — as first-class data, queryable and traversable in ways that document modules cannot match. Flow Engineering takes this approach explicitly: requirements, design artifacts, and traceability relationships are all nodes and edges in a connected model, with AI-assisted analysis layered on top to help engineers understand change impact and coverage gaps at the speed that defense program change cycles demand.

The relevance to defense primes is direct. When a program office issues an engineering change proposal and asks for an impact assessment in 48 hours, the difference between a graph-based requirements model and a DOORS module hierarchy is the difference between a query and a manual review process.

The Supply Chain Problem Nobody Has Solved

Discussion of digital twins in defense acquisition tends to focus on the prime contractor, which is understandable — primes are the contractual interface with the government, and they have the engineering resources and tooling budgets to invest in MBSE. But the digital thread does not stop at the prime’s firewall.

A complex defense system — a ship, an aircraft, a ground vehicle — has thousands of components designed and manufactured by Tier 2 and Tier 3 suppliers. If requirements are flowed down to those suppliers as PDF documents and the suppliers return data as drawings and test reports in whatever format they have available, the digital thread is broken at the subcontract boundary. The prime can have a perfectly connected internal model, and the system-level twin is still incomplete because supplier data lives outside it.

This is not a problem that any single prime contractor can solve unilaterally. It requires government-mandated data standards (the DoD’s Digital Engineering Ecosystem initiatives are working on this, slowly), tooling that is accessible to small and mid-tier suppliers without enterprise software budgets, and subcontract language that specifies not just what data is required but in what format and connected to what identifiers.

The suppliers themselves are in a difficult position. They may be supporting multiple primes, each with its own requirements management toolchain and data exchange format. The investment required to participate fully in multiple digital engineering ecosystems simultaneously is not trivial for a company with fifty engineers.

The Honest Assessment

The DoD’s Digital Engineering Strategy is directionally correct, and the programs where digital engineering has been implemented from program inception show real results: faster change assessment, earlier defect detection, reduced integration risk. The T-7A numbers are real. The change management improvements in naval shipbuilding are real.

The gap between the strategy and the current state of the defense industrial base is also real, and it is not primarily a technology gap. The tools exist. The gap is process, culture, data standards, and — most acutely — the requirements management practices that are supposed to anchor the digital thread but in most programs are still operating in tools and workflows designed for a document-centric world.

Programs that want to close that gap should start with requirements. Not because requirements management is the only component of a digital twin, but because it is the load-bearing structure on which everything else depends. A requirements network that is not live, not graph-connected, and not integrated with the downstream model is a foundation made of paper. Everything built on top of it will reflect that.

The primes that figure this out first — not just in their internal toolchains but across their supply chains — will have a measurable competitive advantage in source selections that are increasingly scoring digital engineering maturity as a capability differentiator. The ones that continue to treat MBSE deliverables as a compliance checkbox will find that the government’s patience for that posture is shortening.