The Digital Thread in Defense Acquisition: Promise vs. Reality

The phrase “digital thread” appears in nearly every major DoD acquisition strategy document published since 2020. The Office of the Secretary of Defense’s Digital Engineering Strategy, first released in 2018, set the ambition clearly: authoritative sources of truth, model-based artifacts replacing document deliverables, and continuous traceability from requirements through test and sustainment. Six years of follow-on guidance, program office directives, and NDAA provisions have reinforced and expanded that ambition.

The ambition is sound. The execution is fractured.

Across major defense programs — in space, aviation, shipbuilding, and ground systems — the distance between what digital thread policy says and what program offices are actually running is substantial. Some programs have genuine, functioning digital threads. Most have a collection of point tools, disconnected models, and PDF deliverables that program managers call “digital” because they are stored in the cloud. Understanding why requires looking honestly at three intersecting problems: legacy tool ecosystems that predate the mandate, contractor incentive structures that reward the appearance of compliance over its substance, and a workforce that is being asked to operate in a new paradigm without adequate transition support.

What the Policy Actually Requires

The DoD Digital Engineering Strategy is not vague. It calls for authoritative digital models as the basis for program decisions, digital artifacts as contract deliverables, and a persistent digital thread that connects every phase of the acquisition lifecycle. The 2022 DoD Data, Analytics, and AI Adoption Strategy added data management requirements that directly bear on thread continuity. More recently, DAF and Army digital engineering implementation plans have translated strategy into program-level expectations — requiring MBSE adoption for major programs and digital artifact libraries in place of traditional data item descriptions.

The Acquisition Pathway reforms under JCIDS have pushed further: digital models are expected to inform requirements validation, not just accompany it. For MDAP-class programs, digital engineering evidence is increasingly expected at Milestone reviews.

That is a coherent, reasonably well-specified mandate. The gap is not in the policy language.

Where Programs Are Actually Succeeding

Some programs have achieved genuine digital thread implementation, and they share identifiable characteristics.

The F-35 program’s digital thread work — while not uniformly celebrated — has produced functioning model-to-manufacturing traceability in specific subsystems, particularly in structural analysis and avionics configuration management. The key enabling factor was early investment in data architecture before tooling decisions, not after. Lockheed Martin built thread infrastructure around a defined data model, then selected tools that conformed to it.

NGAD and next-generation missile programs under development at AFRL have benefited from greenfield starts: no legacy tool debt, smaller program offices with higher MBSE literacy, and contracts written with digital artifact deliverables as primary rather than supplemental. When you write the contract right, you get different contractor behavior.

Space programs under USSF — particularly SDA’s proliferated LEO constellation work — have moved aggressively toward model-based requirements and digital review packages. The SDA’s architecture of rapid acquisition with short design cycles made document-centric processes visibly unworkable, which created organizational pressure that policy alone does not generate.

The common thread across these successes: the digital thread architecture was defined first, at the program level, with clear data standards — and contracts enforced those standards rather than accepting document surrogates.

Where Programs Are Struggling

The struggling programs are more numerous and, frankly, more representative of the defense industrial base.

Large shipbuilding programs present one of the clearest cases of structural friction. The carrier and submarine programs involve hundreds of suppliers, toolchains that were locked in decades ago, and classification requirements that make cloud-based data sharing architecturally complex. The digital thread in a Virginia-class submarine program has to traverse organizational boundaries, classification domains, and tool ecosystems that have accumulated 30 years of technical debt. Integrating modern MBSE tooling into that environment is not a tooling problem — it is a systems integration problem of comparable complexity to the ship itself.

Ground vehicle programs, particularly legacy platform upgrades, face a different version of the same issue. When the baseline design exists as a collection of 2D drawings, thousands of Word documents, and DOORS databases with inconsistent attribute schemas, “creating a digital thread” means either retroactively modeling something that was never designed that way, or accepting a permanent seam between historical and current data. Both options are expensive. Many programs choose a third option: relabel the existing artifacts as “digital” and call it done.

Army C2 and EW programs show a consistent pattern where the program office accepts MBSE-compliant deliverables at contract milestones while the actual engineering work happens in disconnected tools. The model is a deliverable artifact, not an authoritative source. This is what practitioners inside the acquisition community have started calling “digital thread theater” — the performance of compliance without the substance.

The Legacy Tool Problem

The defense industrial base runs on IBM DOORS, Windchill, Teamcenter, legacy MathWorks environments, and decades of accumulated custom tooling. These tools are not going away because a strategy document says to modernize. They contain authoritative program data, have trained user communities, and are embedded in contractual data rights arrangements that make migration legally complicated.

IBM DOORS and DOORS Next hold requirements data for the majority of MDAP programs currently in development or sustainment. DOORS is a capable requirements management tool with deep integration into established contractor workflows. Its limitation in a digital thread context is not that it fails at requirements management — it is that its data model does not naturally connect to the graph-based artifact relationships that a true digital thread requires. Traceability in DOORS is primarily document-to-document or requirement-to-requirement within a defined hierarchy. Threading that data to CAD models, simulation results, test records, and IVV artifacts requires integration work that varies in quality, is rarely standardized across contractors, and breaks whenever either tool updates.

Polarion and Codebeamer — both widely used in aerospace and defense primes — offer richer cross-artifact traceability and are better suited to modern digital engineering workflows than classic DOORS. But they are still being adopted against an installed base that resists displacement, and they require process discipline that takes years to build in large organizations.

The net effect is a tool landscape where data lives in silos that are manually bridged by engineers who export spreadsheets and email PDFs. The digital thread in practice often means “we have PDFs in SharePoint with consistent naming conventions.” That is not nothing, but it is not what the strategy intended.

The Contractor Incentive Problem

Defense contractors are sophisticated organizations that optimize for contract performance. The current contract structures for most MDAPs create stronger incentives for document deliverable compliance than for genuine digital continuity.

A contractor who delivers a compliant Systems Requirements Review package — even if that package is a polished PDF export from a partially maintained DOORS database — has met the contract milestone. A contractor who invests in building a true digital thread, with live traceability from system requirements through subsystem models to test results, has done more expensive work for the same contractual credit. Across thousands of engineers and multiple program years, that incentive differential drives behavior.

Program offices that have broken this pattern have done so by writing digital artifact standards into the Statement of Work at contract inception, specifying the data formats, tool-agnostic data exchange standards (SysML, ReqIF, OSLC), and requiring live model access rather than static deliverables at review events. This shifts the compliance target from document production to data quality. It requires more sophisticated program management capability, but it produces materially different contractor behavior.

The challenge is that this sophistication is unevenly distributed across program offices, and contracting officers are not always equipped to evaluate digital artifact quality the way they can evaluate a document deliverable.

The Workforce Problem

The human capital dimension of digital thread adoption is consistently underestimated. MBSE is not simply a new tool — it is a different way of reasoning about system architecture. Engineers trained in document-centric processes can learn MBSE tools, but developing genuine model-thinking fluency takes years of practice and organizational reinforcement.

The DoD civilian workforce has some of the best systems engineers in the world, but the transition to MBSE is uneven. Program offices that have invested in training and kept experienced MBSE practitioners in continuity roles are measurably ahead. Those that have treated MBSE as a tool procurement problem — buy Cameo, install it, done — have tool licenses and no capability.

The contractor workforce mirrors this. Large primes have MBSE centers of excellence with genuine depth. But the first-tier and second-tier suppliers that make up the bulk of complex program supply chains often do not. When a prime contractor’s digital thread depends on structured data from 150 suppliers with varying MBSE maturity, the thread quality is bounded by the lowest common denominator.

How Modern Tool Architectures Are Helping

Some of the structural friction is being reduced by a generation of tools designed from the beginning for connected, model-centric work rather than retrofitted to it.

Tools like Flow Engineering — built specifically for hardware and systems engineering teams — approach requirements management as a graph problem rather than a document problem. Requirements exist as nodes with typed relationships to design artifacts, test cases, risk items, and verification evidence. Traceability is not a report you generate at milestone time; it is a live property of the data model that engineers interact with daily. When a requirement changes, the impact propagates visibly through the graph, surfacing the downstream artifacts that need review.

This architecture makes it materially easier to build and maintain a genuine digital thread, because the tool’s data model aligns with what a digital thread actually is: a connected graph of authoritative artifacts. The practical effect for program teams is that the model is not a separate deliverable — it is the working environment.

This does not eliminate the integration problem with legacy systems or the workforce readiness problem. But it changes the default. When the tool’s native behavior produces traceability, engineers have to work against the grain to break it.

What a Working Digital Thread Actually Requires

Programs that want to close the gap between policy and reality need to address all three problem dimensions, not just one.

On tools: define the data architecture and exchange standards before selecting tools. Require tool-agnostic data interchange (ReqIF for requirements, OSLC for cross-tool linking) in contracts. Do not accept PDF exports as digital artifacts.

On contracts: write digital artifact quality standards into the SOW. Require live model access at review events. Create contractual definitions of “authoritative source” that exclude static files.

On workforce: invest in MBSE education that goes beyond tool training. Build organizational structures — digital engineering leads, thread architects — that maintain continuity across the program lifecycle. Evaluate and mature supplier MBSE capability as part of source selection.

Honest Assessment

The DoD’s digital engineering mandate reflects genuine strategic understanding of where defense acquisition needs to go. Connected, model-based programs make better decisions faster, catch integration problems earlier, and produce sustainment data that actually supports the warfighter over decades of system life.

The gap between that intent and current field reality is real and large. It will not close through policy intensity alone. The programs that are succeeding have invested in the unglamorous infrastructure work — data architecture, contract language, workforce development — that makes the mandate operational rather than nominal.

The programs that are struggling are, in most cases, not failing because of bad intent. They are failing because the transition from document-centric to model-centric engineering is genuinely difficult across organizations with deep legacy investments in both tools and habits. The mandate is real. The barriers are real. Closing the gap requires taking both seriously.