Model-Based Definition Is Now a Defense Mandate: What the Next Five Years Look Like for the Industrial Base
From DCSA directives to MIL-DTL-31000C, MBD is moving from best practice to contractual requirement — and the toolchain implications are significant.
For the past decade, Model-Based Definition occupied a strange position in defense manufacturing: universally endorsed, inconsistently practiced, and rarely enforced. Prime contractors ran internal MBD initiatives. Suppliers attended training. Standards committees published guidance. And engineers continued emailing 2D drawings because that’s what worked.
That window is closing. Three converging forces — DCSA’s evolving audit requirements, the DoD’s digital thread mandate, and the 2023 revision of MIL-DTL-31000C — have shifted MBD from aspirational to contractual. For defense engineering teams, the question is no longer whether to adopt MBD, but how quickly they can make it mean something beyond annotated geometry.
What’s Actually Driving This
DCSA and the Audit Pressure
The Defense Counterintelligence and Security Agency has expanded its technical data package (TDP) review criteria to include format and completeness requirements that implicitly favor — and in some cases explicitly require — MBD-compliant deliverables. DCSA’s interest is partly security-driven: annotated 3D models with embedded manufacturing instructions reduce the risk of drawing misinterpretation and unauthorized modification, both concerns that map directly to supply chain integrity.
More practically, when DCSA auditors review a TDP for a classified program, a 2D drawing set with separate specifications and tolerances is increasingly viewed as incomplete. The data exists in multiple documents, maintained separately, with no enforced consistency. From a configuration management standpoint, that’s a liability.
MIL-DTL-31000C
The 2023 revision of MIL-DTL-31000C — the military detail specification governing TDPs — made substantive changes that are still propagating through contracting offices. The updated language defines a compliant TDP as one that can support the full product lifecycle through a single authoritative source, and it explicitly recognizes MBD datasets as a primary deliverable format alongside, and eventually instead of, 2D drawings.
Contracting officers are still learning what this means in practice. But programs starting formal design reviews in 2026 and beyond are increasingly citing MIL-DTL-31000C compliance as a deliverable criterion. That citation is now showing up in RFPs, not just program office guidance documents.
The Digital Thread
The DoD’s digital engineering strategy, published in 2018 and operationalized slowly since, places the digital thread at the center of its acquisition modernization vision. The concept is straightforward: a single, authoritative data linkage that connects requirements through design, manufacturing, testing, and sustainment — accessible across the lifecycle without manual re-entry.
MBD is the design node of that thread. If the 3D model is the authoritative source for geometric and manufacturing data, then the digital thread requires that model to be queryable, traceable, and connected to upstream requirements and downstream manufacturing instructions. A model that exists in a CAD vault, disconnected from requirements and change history, doesn’t serve the thread — it just moves the document problem into a different file format.
This is where most programs are currently failing, and it’s where the next five years will be decided.
The Cross-Contractor Problem Nobody Has Solved
MBD works reasonably well inside a single organization using a single CAD platform. Lockheed Martin using NX across its Aeronautics division can maintain consistent PMI (Product and Manufacturing Information) annotation standards, enforce model quality through internal review gates, and connect model attributes to its PLM system. That’s achievable, and several primes have done it.
The problem is that defense programs don’t operate inside a single organization. An aircraft program might involve a prime using Creo, a major subcontractor running CATIA, three tier-two suppliers on SolidWorks or Inventor, and a handful of small machine shops that have never opened a 3D viewer. The model hand-off chain degrades at every step.
STEP AP242 and JT are the two dominant neutral format options for MBD exchange, and both have improved substantially. STEP AP242 (the 2014 revision focused on MBD) can carry PMI data — tolerances, surface finish callouts, material specifications — in a format that any compliant viewer can render. JT, backed by Siemens and now an ISO standard, is lighter-weight and better suited to visualization.
The problem isn’t format capability. It’s semantic fidelity. When a model moves from NX to a STEP AP242 file to a supplier’s Creo environment, the geometry transfers intact. The PMI annotations usually transfer visually. But the semantic connections — the associations between a dimension and the requirement it implements, the change history that explains why a tolerance was tightened — typically don’t survive the translation.
What arrives at the supplier is a frozen snapshot, not a connected artifact. The supplier can manufacture to the model, but they can’t query it, trace from it, or update it in a way that propagates back upstream. The digital thread, at that link, is broken.
Several programs have attempted to address this through strict model preparation standards — ASME Y14.41, NATO STANAG 4694 — and supplier qualification requirements. These help with annotation consistency but don’t solve the semantic connectivity problem. That requires architectural decisions that most defense supply chains haven’t made yet.
Where MBD and Systems Engineering Intersect
The frame of “MBD as a CAD feature” is the wrong frame. It produces technically correct annotated models with no connection to the systems engineering artifacts that drove the design decisions embedded in them.
Consider a geometric tolerance on a mating surface. That tolerance exists because a requirement — probably a performance requirement, possibly derived from an interface definition — demanded a specific fit and function. In a document-centric world, a systems engineer wrote the requirement, a design engineer read it, set a tolerance, and the connection between the two lived in someone’s head or a manually maintained requirements traceability matrix.
In a properly implemented MBD environment, that connection is explicit and queryable. The tolerance annotation in the model references the requirement that generated it. Change the requirement, and the system flags the model annotation for review. Change the tolerance, and the change propagates to whatever assembly or test procedure depends on that fit.
This is not how most programs currently use MBD. Most programs use it as a drawing replacement — better drawings, in 3D, with annotations. The traceability connection to requirements is either absent or maintained manually in a separate tool.
The programs that are actually implementing digital thread concepts are those where the systems engineering organization has a seat at the MBD toolchain decision. They’re asking: how does this model connect to requirements? How does a requirement change trigger a review of affected model annotations? How do we know, at any point, which requirements are fully allocated down to implemented geometry?
Those are systems engineering questions, not CAD questions. The toolchain decisions that answer them span requirements management, model-based systems engineering (MBSE), and PLM — and the seams between those tools are where most programs are struggling.
What Modern Tooling Can Actually Do
PLM platforms from PTC, Siemens, and Dassault have added requirements management modules and digital thread connectors over the past several years. Windchill RV&S, Teamcenter Requirements, and ENOVIA all provide some level of requirements-to-model linkage. These work, with significant configuration effort, within their respective ecosystems.
The gap emerges at the systems engineering layer — where requirements are written, derived, and allocated before they ever reach a CAD tool. Traditional requirements management tools like IBM DOORS and Jama Connect were built around documents and structured text. Connecting them to model attributes requires custom integrations, usually through ReqIF export and import, that are brittle and require manual maintenance.
This is where newer tooling built on graph-based architectures has a structural advantage. Tools like Flow Engineering, which model requirements and their relationships as a live graph rather than a document hierarchy, can maintain explicit, queryable connections between requirements and downstream design artifacts — including model annotations — without requiring manual RTM maintenance. When a requirement changes, the graph propagates the change through its dependency chain, surfacing every downstream artifact that needs review.
For defense programs pursuing genuine digital thread implementation, this matters. The 3D model isn’t the top of the chain — it’s the middle. Requirements live above it; manufacturing instructions, test procedures, and sustainment data live below it. A graph-based requirements layer that can connect upward to mission requirements and downward to model annotations is the architecture the digital thread actually demands.
Flow Engineering’s focus on hardware and systems engineering teams, rather than software development, also means it handles the artifact types defense engineers actually work with: interface control documents, FMEA linkages, hardware requirements with physical constraints, and the derived requirement chains that connect system-level performance to component-level geometry.
What Supplier Qualification Will Look Like by 2030
The trajectory is clear even if the timeline is uncertain. Within five years, the defense industrial base will see:
Tiered MBD requirements in RFPs. Prime contractors will specify not just that deliverables must be MBD-compliant, but what semantic content the model must carry — which requirements must be traceable from model annotations, which change history must be embedded, which simulation results must be associated.
Supplier qualification gates based on MBD capability. Programs modeled on the CMMC (Cybersecurity Maturity Model Certification) approach will likely emerge for digital engineering capability. Suppliers that can’t demonstrate a live requirements-to-model connection will be excluded from certain program tiers.
Neutral format requirements with semantic content. STEP AP242 will likely be required not just for geometry and PMI but for embedded requirements references — model attributes that carry requirement identifiers traceable to the program’s authoritative requirements database.
Audit trails as contractual deliverables. DCSA and program offices will want to see not just the model as it exists at delivery, but the change history that produced it, with traceability to the requirement changes that drove design modifications.
The Honest Assessment
MBD adoption across the defense industrial base is a decade behind where it should be, and the mandate pressure now arriving is partly a consequence of that gap. The standards, the tools, and the contractor capability to implement MBD properly have existed in some form since the early 2010s. What’s been missing is enforcement.
That enforcement is now arriving, unevenly and with significant interpretation variation across contracting offices. Large primes are generally ready, or can get ready quickly. Their tier-one suppliers are mixed. Tier-two and below are largely unprepared.
The programs that will succeed aren’t the ones with the best-annotated models. They’re the ones that have made the connection between their requirements architecture and their model architecture explicit, queryable, and maintainable across the supply chain. That’s a systems engineering problem that needs a systems engineering solution — and the toolchain decisions being made right now will determine which organizations can compete for next-generation programs and which ones spend the next five years retrofitting.
The geometry problem is solved. The connectivity problem isn’t. That’s where the work is.