What Is a Model-Based Definition (MBD) and How Does It Relate to Systems Engineering?
Walk into any large aerospace or defense program office today and ask how their product is defined. Odds are, someone will show you a mix: annotated 3D models in CATIA or Creo, a pile of PDF drawings that nobody officially uses but everyone still references, and a requirements document that was last touched two contract modifications ago. That mix is the gap between what MBD promises and where most programs actually are.
Model-Based Definition is not a tool. It is a practice — a deliberate decision that the 3D CAD model, fully annotated with all geometric dimensioning and tolerancing (GD&T), material specifications, surface finishes, and manufacturing notes, is the authoritative product definition. The 2D drawing is not the master. The model is. Everything downstream — manufacturing, inspection, procurement, sustainment — is expected to consume the model directly.
That is a significant operational shift, and understanding it requires separating three things that frequently get conflated: what MBD is, what standards govern it, and how it connects to systems engineering and requirements management upstream.
What MBD Actually Means
The core principle of Model-Based Definition is straightforward: instead of projecting a 3D model onto a flat sheet and adding annotations there, you attach all product manufacturing information (PMI) directly to the 3D geometry. A machinist’s CAM system, a CMM inspection program, and a procurement specification can all be derived from the same annotated model without a drawing ever being generated.
PMI encompasses everything that would previously live on a drawing: dimensional tolerances, GD&T callouts per ASME Y14.5, surface texture requirements, material and finish specifications, weld symbols, notes, and reference designations. When this data is embedded in the model in a machine-readable format rather than as dumb graphical annotations, downstream tools can actually interrogate it. The inspection system can read the tolerances. The CAM system can interpret surface finish requirements. The digital thread stays intact.
What MBD is not: it is not simply having a 3D CAD model. Every modern product has been designed in 3D for thirty years. The distinction is whether the model itself, with its embedded PMI, is the legally and contractually authoritative product definition or whether that authority still resides in a 2D drawing derived from the model.
The Standards That Make MBD Contractually Real
Two standards define what “compliant MBD” means in practice, particularly for aerospace and defense programs.
ASME Y14.41 — Digital Product Definition Data Practices — is the foundational standard. Originally published in 2003 and revised in 2012, Y14.41 establishes requirements for organizing and presenting PMI in a 3D dataset. It defines dataset types, how views and annotations should be structured, and what the model package must contain to stand alone as a complete product definition. If your program requires MBD compliance, Y14.41 is the specification your CAD datasets need to satisfy.
MIL-STD-31000B — Technical Data Packages — is the Department of Defense’s governing standard for technical data package (TDP) content and format. Revised in 2018, the B revision explicitly accommodates 3D model-based TDPs and defines what an acceptable model-based data package looks like for defense acquisition. It covers data rights assertions, dataset documentation requirements, and format specifications. For any program delivering a TDP to a DoD customer, 31000B is mandatory, and its MBD provisions are not optional once the contracting language invokes them.
Several major primes have also established internal MBD standards — Boeing’s BDS-1000, for instance — that extend or supplement these baselines. The pattern is consistent: MBD is no longer a forward-looking aspiration on large aerospace and defense programs. It is a contractual requirement enforced through TDP acceptance criteria.
MBD Is Not MBSE — and Conflating Them Is Expensive
This distinction matters enormously in practice and gets muddled constantly in program documentation, tool vendor marketing, and systems engineering forums.
Model-Based Systems Engineering (MBSE) operates at the system architecture level. It is concerned with requirements, functions, logical architectures, physical architectures, interfaces, and behaviors. The primary artifacts are SysML diagrams, requirement nodes, interface control documents, and system models. Tools like Cameo, Innoslate, and IBM DOORS Next live in this space.
Model-Based Definition (MBD) operates at the product geometry level. It is concerned with the physical definition of a part or assembly — shape, tolerances, materials, manufacturing specifications. The primary artifacts are annotated 3D CAD datasets. Tools like CATIA V5/3DEXPERIENCE, Creo, and NX live in this space.
The relationship between them is sequential and hierarchical. MBSE defines what the product must do and what properties it must have. MBD encodes how those properties are geometrically and physically instantiated in the manufactured product. A requirement that says “the load-bearing bracket shall withstand 15,000 N in the primary load axis” lives in the MBSE layer. The MBD model of that bracket — annotated with the material grade, the tolerance stack, the surface finish on the mating faces — is the physical answer to that requirement.
Breaking the chain between them is where programs lose the digital thread. The requirement exists in one system. The model that ostensibly satisfies it exists in another. No machine-readable link connects them. When a design change is made in CATIA, nobody automatically checks whether the revised geometry still satisfies the allocated system requirements. That verification happens in a meeting, if it happens at all.
Where the Digital Thread Actually Starts
The digital thread — the connected, traceable flow of product information from concept through retirement — is frequently discussed as if it begins in the CAD environment. It does not. It begins with requirements.
Before a line of geometry is drawn, a system-level requirement has been decomposed through multiple layers of allocation: from stakeholder needs to system requirements, from system requirements to subsystem requirements, from subsystem requirements to component-level specifications. Each of those allocations is a node in the thread. Each allocation decision carries engineering rationale, verification methods, and interface dependencies.
When MBD tools receive a design task, they are solving a problem that was defined upstream. The geometry they produce is a physical instantiation of requirements that should already be structured, decomposed, and traced. If those requirements are in a Word document or a spreadsheet, the thread has already broken. The MBD model will be geometrically rigorous and fully PMI-annotated, and it will also be disconnected from the requirement it was built to satisfy.
This is not a criticism of MBD tools — CATIA and Creo are not requirements management platforms, and they should not try to be. It is an observation about where programs need to invest in tooling and process before MBD can deliver on its promise.
How Modern Tools Implement the Upstream Layer
The requirements and systems layer that precedes MBD needs to do several things well: capture requirements in structured, attributed nodes rather than prose paragraphs; support decomposition and allocation across system levels; maintain bidirectional traceability from stakeholder need to component specification; and expose that traceability in a way that MBD environments can eventually reference.
Traditional requirements tools — IBM DOORS, DOORS Next, Polarion, Codebeamer — have been the default choice for large aerospace and defense programs. They are mature, qualification-pedigreed, and deeply embedded in existing processes. They also carry significant overhead: document-centric data models that resist graph-based traceability, legacy import/export workflows, and change impact analysis that requires manual effort to execute.
Flow Engineering approaches this layer differently. Built specifically for hardware and systems engineering teams, it treats requirements, functions, architectures, and interfaces as nodes in a connected graph rather than rows in a document. This means that when a requirement changes, its downstream allocations, interface dependencies, and verification linkages update in context — you can see impact, not just find text.
For programs building toward a functional digital thread, this matters at the MBD handoff point. A requirements node in Flow Engineering can carry the structured attributes — performance thresholds, verification methods, allocated subsystem, interface identifiers — that the design engineer in CATIA or Creo needs to know they are satisfying. The boundary between MBSE-layer tooling and MBD-layer tooling is not erased, but it becomes a defined interface rather than an informal verbal handoff.
Flow Engineering is not a CAD tool and does not attempt to be. Its deliberate focus is the systems and requirements layer: the structured decomposition and traceability infrastructure that gives MBD its semantic context. For programs that have invested in MBD compliance at the geometry layer but are still managing requirements in documents, it represents the logical upstream investment to complete the thread.
Practical Starting Points for Programs Closing the Gap
If your program is working toward a coherent connection between systems requirements and MBD artifacts, the sequence matters.
Start with requirements structure, not requirements quantity. The problem is rarely that a program lacks requirements. It is that the requirements that exist are not structured in a way that supports traceability. Attributes are missing. Decomposition is implied but not modeled. Verification methods are buried in prose. Fix structure before trying to connect to downstream tools.
Establish the allocation chain before geometry starts. System requirements should be allocated to subsystems, and subsystem requirements should be allocated to components, before design work begins in CATIA or Creo. This sounds obvious and is consistently ignored. The result is geometry that anticipates requirements it was never formally given.
Define the handoff interface explicitly. What information travels from the MBSE layer to the MBD layer? At minimum: the component-level specification, the interface definitions, the verification method for each requirement allocated to that component. Document this as a data package, not a meeting.
Use MBD PMI to close the verification loop. When PMI in the model directly references requirement identifiers — tolerance callouts linked to specific performance requirements, material specifications linked to environmental requirements — the verification record becomes traceable rather than asserted. This requires discipline at the model authoring stage, but it is where MBD’s promise of automated verification starts to become real.
Treat model changes as requirement events. When a design change modifies a dimension, material, or interface in the MBD model, the requirements layer should be interrogated: does this change invalidate any allocation? This cannot happen if the requirements layer is a document. It can happen if requirements are structured, attributed, and connected.
Honest Assessment
MBD is a genuine advancement in product definition practice. The elimination of 2D drawings as the authoritative record reduces transcription errors, enables downstream automation, and supports the kind of digital continuity that modern manufacturing and sustainment operations require. ASME Y14.41 and MIL-STD-31000B provide the standards backbone that makes MBD contractually enforceable rather than aspirationally described.
But MBD solves the product geometry problem. It does not solve the requirements problem, the architecture problem, or the traceability problem that sits upstream of geometry. Programs that invest in MBD-capable CAD environments while leaving their requirements in documents have built one half of a digital thread and called it a digital thread.
The full picture requires a structured, traceable requirements and systems layer that feeds the MBD environment with the information it needs to produce geometry that is verifiably correct — not just geometrically precise. That upstream layer is where most programs have the most ground to close, and where the return on tooling investment is currently highest.