What Model-Based Definition Actually Means

Model-Based Definition (MBD) is the practice of embedding all product and manufacturing information (PMI) directly in a 3D CAD model, making that model the single authoritative source for design, manufacturing, inspection, and sustainment. Geometric dimensioning and tolerancing (GD&T) annotations, surface finish callouts, material specifications, assembly notes, and inspection criteria live on or within the 3D geometry itself—not in a separate 2D drawing that references the model.

The operative word is authoritative. A 3D model that exists alongside a 2D drawing is a visualization aid. A 3D model that replaces the drawing—from which downstream processes pull directly—is MBD. That distinction matters in procurement contracts, manufacturing floor instructions, and certification submissions.

MBD does not mean abandoning drawings in every regulatory context. Some certification bodies still require drawing packages. What MBD changes is the source of truth: geometry and its associated information originate in the model, and any 2D output is derived from it, not the reverse.

The Core Technical Concepts

Product and Manufacturing Information (PMI)

PMI is the structured dataset that would previously have lived on a drawing. In MBD, it is stored as model-attached annotations and metadata that downstream tools—CAM software, CMM inspection programs, ERP systems—can read programmatically without a human transcribing dimensions from paper.

Standards that govern PMI format include:

  • ASME Y14.41 — the U.S. standard for digital product definition data practices
  • ISO 16792 — the international equivalent
  • MIL-STD-31000B — the U.S. DoD technical data package (TDP) standard that formally recognizes 3D TDPs as contract-deliverable artifacts

When PMI is authored correctly and consumed by capable downstream tools, it eliminates the transcription errors that occur when machinists re-interpret 2D drawings. When it is authored inconsistently—tolerances buried in text fields, GD&T applied informally—MBD produces the same errors it was meant to prevent, just earlier in the process.

The Annotated Model vs. the Associative Model

There are two distinct levels of MBD practice. In an annotated model, PMI is added as display annotations—human-readable but not necessarily machine-readable. In a fully associative model, PMI is parametrically tied to geometry so that a dimensional change propagates correctly to the annotation and, from there, to downstream toolpaths and inspection routines.

Most programs using MBD today operate somewhere between these two levels. Annotated models are common. Fully associative implementations with closed-loop downstream consumption are less common and significantly harder to achieve across a multi-tier supply chain.

The Digital Thread Connection

The digital thread is the communication framework that links data across a product’s lifecycle—from early requirements through design, manufacturing, test, sustainment, and disposal. MBD is the design-and-manufacturing segment of that thread. It is one node, not the whole thread.

This distinction is important because MBD is frequently discussed as if it is the digital thread, or as if implementing MBD automatically produces end-to-end traceability. It does not. The thread requires upstream anchors—primarily system requirements—and downstream consumers—manufacturing execution systems, test data repositories, and maintenance records—to be connected. Without those connections, an MBD model is a very well-annotated file in a PDM vault, not a live node in a traceable system.

Adoption Patterns: Aerospace and Automotive

Aerospace

Aerospace has the longest MBD history of any industry. Boeing’s 777 program (early 1990s) is the canonical reference point: it was designed entirely in CATIA with no full-size physical mockup, a first for a commercial aircraft. The discipline that makes that possible is not just 3D modeling—it is the downstream consumption of that 3D data by manufacturing and assembly systems.

Today, U.S. defense programs are increasingly required to deliver 3D TDPs under MIL-STD-31000B. AS9100 Rev D does not mandate MBD explicitly, but its emphasis on configuration management and product realization creates strong incentives for structured 3D data practices. Primes like Lockheed Martin, Northrop Grumman, and Airbus have internal MBD mandates that cascade to suppliers via contract data requirements lists (CDRLs).

The aerospace challenge is not whether to adopt MBD but how to extend it through a supply chain where Tier 2 and Tier 3 suppliers may still be operating on 2D drawing workflows. Model translation fidelity—whether PMI survives export from one CAD format to another—is an unsolved problem at scale.

Automotive

Automotive adoption accelerated as OEMs adopted MBSE (Model-Based Systems Engineering) for full-vehicle development. In an MBSE program, system architecture is defined in SysML or similar notation before the CAD model exists. MBD then becomes the downstream expression of decisions made in the system model. The digital thread, in this context, runs from system requirements through the architecture model through MBD geometry through manufacturing.

German OEMs and their Tier 1 suppliers are furthest along, partly because of AUTOSAR (Automotive Open System Architecture) discipline and partly because of regulatory pressure from functional safety standards like ISO 26262, which require traceable evidence that every safety requirement is implemented in physical design. MBD with proper upstream traceability can provide that evidence. MBD without it cannot.

The Traceability Gap: MBD’s Persistent Problem

Here is where most MBD implementations fall short. The question that a model-based definition cannot answer from within the model itself is: why does this geometry have these tolerances?

That answer lives in requirements. A specific surface flatness callout exists because a system requirement specified a sealing load. A specific material callout exists because a thermal environment requirement drove a conductivity constraint. A specific hole pattern exists because an interface control document specified a bolt pattern from a mating assembly.

In a 2D drawing world, this connection was never clean either—engineers used document numbers and informal notes. But in an MBD world, where the claim is that the model is the single source of truth, the absence of upstream traceability is more visible and more damaging. You can audit a 3D model and verify it satisfies its drawing callouts. You cannot audit a 3D model and verify it satisfies its system requirements unless those requirements are formally connected to it.

The practical consequence shows up in three scenarios:

Change impact analysis. When a system requirement changes, engineers need to know which models are affected. Without a requirements-to-model link, they search manually. Manual searches miss things.

Certification and compliance. Certification bodies increasingly ask for evidence that design artifacts are traceable to requirements. An MBD model with no upstream traceability forces engineers to reconstruct that evidence at submission time, which is expensive and error-prone.

Variant and derivative management. When a product family shares common geometry but different performance requirements, the model alone does not tell you which requirement drove which feature. Without that record, derivative programs inherit decisions without understanding the constraints behind them.

How Modern Requirements Tools Anchor the Upstream Thread

Closing the traceability gap requires a requirements management layer that can link structured requirements to MBD artifacts—not just to documents, but to specific model elements, annotations, or configurations.

Legacy requirements tools handle this poorly. IBM DOORS and DOORS Next can store requirements and export them in various formats, but their data models are fundamentally document-centric. Linking a DOORS module entry to a specific PMI annotation in a CATIA model requires custom scripting or middleware, and maintaining that link as both the requirements and the model evolve requires process discipline that most programs do not sustain.

Newer tools built on graph-based data models handle this more naturally. A graph-based approach stores requirements, design artifacts, test records, and their relationships as nodes and edges in a connected structure. A change to a requirement propagates through the graph immediately, and engineers can query the graph to find all model elements connected to a given requirement—or all requirements affecting a given model element.

Flow Engineering takes this approach for the upstream requirements layer. Its graph-based architecture is designed for hardware and systems programs, and its traceability model connects requirements to downstream artifacts—including MBD outputs—through explicit, queryable relationships rather than document cross-references. For programs trying to anchor the upstream end of an MBD digital thread, this means requirements exist as live nodes that design teams can point to when annotating models, and that program managers can query when assessing change impact.

Flow Engineering’s scope is deliberately focused on the requirements and systems engineering layer. It is not a PDM system, a CAD platform, or a full PLM suite. That focus is the source of its coherence—it does not try to replace the tools that manage geometry, it connects to them as an upstream anchor. Programs need to make an explicit integration decision about how Flow Engineering links to their CAD and PLM stack, and that integration work is real. But the alternative—managing upstream requirements in a document-based system that has no awareness of MBD artifacts—leaves the traceability gap open.

Practical Starting Points

If your program is beginning or maturing an MBD implementation, the traceability question should be addressed before you finalize your toolchain:

1. Define what “authoritative” means contractually. Before annotating a single model, confirm whether your customer and your certification authority will accept a 3D TDP. Document that acceptance. Do not assume.

2. Audit your PMI authoring standards. Consistency in how annotations are structured determines whether downstream tools can read them. Inconsistent PMI creates the same errors as inconsistent drawings, just in different places.

3. Map the upstream gap now. Identify which system requirements drive which geometry decisions, even informally. That mapping is the foundation of your requirements-to-model traceability. Starting this late in a program is expensive.

4. Choose a requirements layer that can connect to model artifacts. The right tool depends on your program’s complexity and your existing stack. Tools that use graph-based traceability make this connection more maintainable than document-based alternatives.

5. Plan for supply chain translation. If your suppliers work in different CAD systems, validate that PMI survives the translation. This is a toolchain qualification task, not an assumption.

MBD is a genuine improvement over drawing-based workflows when implemented with discipline. Its persistent limitation is not geometric—3D geometry is mature technology. The limitation is that the practice evolved primarily as a manufacturing efficiency tool and its connection to the systems engineering layer that generates requirements was treated as someone else’s problem. For programs where traceability is a certification requirement or a change management imperative, that gap needs to be closed deliberately, from both ends.