MBD vs. 2D Drawings: Traceability, GD&T, and Inspection

What is the difference between Model-Based Definition and 2D drawings?

The primary difference between model-based definition (MBD) and 2D drawing-based workflows is the authoritative source of product definition. In a drawing-based approach, engineering requirements are communicated through released drawings. In MBD, the annotated 3D model becomes the authoritative source, connecting design, manufacturing, inspection, and quality data to a common digital definition. The table below compares how the two approaches differ across key engineering and quality processes.

Model-Based Definition vs. 2D drawings at a glance

How does traceability differ between Model-Based Definition and 2D drawings?

In a 2D drawing-based workflow, traceability depends on keeping several controlled documents consistent with one another. In a model-based definition (MBD) workflow, traceability is centered on a single authoritative dataset.

With drawings, requirements are distributed across the CAD model, released drawing sheets, inspection documentation, and quality records. To demonstrate that a requirement was manufactured and verified correctly, teams must cross-reference dimensions and GD&T callouts on the drawing against ballooned characteristics and recorded inspection results, often manually.

With MBD, PMI and GD&T are attached directly to model geometry. Each characteristic can carry a persistent identifier tied to the feature it controls, and that identifier can follow the requirement into inspection plans, measurement results, and quality records. This lets a requirement be traced from design intent through verification without re-entering it at each stage.

This distinction becomes particularly important in industries where conformance must be demonstrated against a specific revision, such as aerospace and defense programs with long service lives, configuration audits, and multi-tier supply chains. MBD traceability is only as strong as the governance around it: the model must be released under configuration control, and derivatives sent to suppliers, such as STEP AP242 or 3D PDF files, must be validated against it.

How are PMI and GD&T handled in MBD versus 2D drawings?

Drawing-based workflows communicate PMI and GD&T as annotations for people to interpret. MBD attaches the same information directly to model geometry, and when that PMI is semantic, both people and software can use it.

On a 2D drawing, product manufacturing information (PMI) and geometric dimensioning and tolerancing (GD&T) appear as dimensions, notes, symbols, and feature control frames placed on 2D views. Manufacturing, quality, and inspection teams read those annotations and manually transfer the requirements into machine programs, inspection plans, and other downstream systems.

In an MBD workflow, dimensions, tolerances, datum references, surface finish specifications, and notes are associated with the 3D features they control. PMI comes in two forms. Graphical PMI is a visual presentation of requirements for people to read. Semantic PMI is structured, machine-readable data that software can interpret. With semantic PMI, CAM, CMM, inspection, and tolerance analysis tools can consume requirements directly from the model, for example by extracting inspection characteristics automatically, instead of relying on manual re-entry.

What a downstream consumer can do with PMI depends on how it is delivered. Native CAD formats and STEP AP242 can carry semantic PMI, but only when both the authoring and consuming systems support it. Depending on the translation workflow, semantic PMI may be preserved, simplified, or reduced to graphical annotations. 3D PDFs and lightweight viewers let suppliers see and query PMI but generally do not pass it into their own manufacturing or inspection software.

How does first article inspection differ between MBD and 2D drawings?

In a drawing-based workflow, first article inspection (FAI) starts with manually ballooning a released drawing to build the list of characteristics to inspect. In a model-based definition workflow, that list can be extracted from the model’s PMI, and each characteristic stays linked to the feature it governs and the result that verifies it. The inspection itself is still required; what changes is how characteristics are identified, recorded, and traced.

First article inspection step by step

How MBD affects AS9102 forms

In aerospace, FAI is typically documented on the three AS9102 forms, and MBD affects each one differently:

• Form 1 (Part Number Accountability) identifies the part and revision inspected. Under MBD, it references the revision of the model dataset rather than a drawing.
• Form 2 (Product Accountability) records materials, special processes, and functional testing. It is largely unchanged, although specifications called out in model notes can be pulled from PMI.
• Form 3 (Characteristic Accountability) changes the most. The characteristic list comes from PMI instead of balloons, and each recorded result traces back to a specific model feature.

What MBD doesn’t change in first article inspection

Automated extraction depends on semantic PMI; where a model carries only graphical PMI, characteristics still have to be identified manually, even if digitally. Quality engineers still review extracted characteristics, approve inspection plans, and disposition nonconformances.

The same shift applies outside aerospace. In automotive PPAP, dimensional results can be tied to model characteristics instead of a ballooned print, and medical device manufacturers can link design verification evidence to the controlled product definition.

The table below compares each step of the FAI process under a drawing-based and a model-based workflow.

How do MBD and 2D drawings support configuration control and revision integrity?

Both approaches can support formal configuration management, but they control different things. A drawing-based workflow has to keep the model, drawings, and related records released and synchronized at the same revision. An MBD workflow manages the authoritative product definition as a single controlled dataset. This reduces the risk of a drawing and model drifting out of sync, but it increases the importance of controlling the derivative files generated from that dataset.

Configuration control within the enterprise

With drawings, every engineering change means revising, approving, and releasing the model and its drawing sheets together, then confirming that downstream teams have the matching revision of each. With MBD, PMI and GD&T are revised along with the geometry, so there are fewer documents to reconcile, and changes can be compared at the feature level to see which characteristics are affected.

In both cases, a PLM or PDM system usually manages release workflows, revision history, and effectivity, which records which revision applies to which serial numbers, lots, or production dates.

Revision integrity across the supply chain

With drawings, suppliers typically receive a drawing package and confirm its revision against the purchase order. With MBD, suppliers may receive native CAD files, STEP AP242 models, 3D PDFs, or viewer-based representations, all of which must trace back to the released model. Keeping revision integrity across the supply chain therefore depends on controls such as:

• generating derivatives only from the released model, labeled with its revision
• validating each derivative’s geometry and PMI against the master dataset
• using checksums, digital signatures, or controlled distribution so suppliers and auditors can verify they have the correct release
• recording which revision and format each supplier received and built to

Why revision integrity matters for configuration audits

In aerospace and defense, functional and physical configuration audits (FCA and PCA) require evidence that delivered hardware matches a specific released configuration, sometimes many tiers down the supply chain. Medical device and automotive manufacturers face similar expectations through design history files and PPAP records.

What standards govern Model-Based Definition?

No single standard governs model-based definition. MBD relies on a set of standards that work together: ASME Y14.41 and ISO 16792 define how annotated models are prepared, ASME Y14.47 defines how they are organized, ASME Y14.5 and ISO GPS define the GD&T they carry, STEP AP242 and QIF define how model and inspection data are exchanged, and MIL-STD-31000B defines how model-based technical data packages are delivered to the U.S. Department of Defense. Quality standards such as AS9100 then set the evidence requirements that MBD data must satisfy.

ASME Y14.41

ASME Y14.41, Digital Product Definition Data Practices, is the core U.S. standard for MBD. It defines how dimensions, tolerances, datums, notes, and other PMI are applied to and presented in a 3D model, so that an annotated model can serve as the authoritative product definition, with or without accompanying drawings.

ISO 16792

ISO 16792 is the international counterpart to ASME Y14.41 and is closely aligned with it. Organizations with global supply chains often reference both.

ASME Y14.47

ASME Y14.47, Model Organization Practices, defines how the content of a model-based dataset is structured, including geometry, PMI, views, and supporting data, so that downstream users can find and interpret requirements consistently.

ASME Y14.5 and ISO GPS

ASME Y14.5 defines the GD&T language used across most U.S. industries, including aerospace and defense, while ISO GPS standards such as ISO 1101 serve the same role internationally. MBD changes where tolerances are stored and how they are consumed, not the GD&T rules themselves.

STEP AP242

STEP AP242 (ISO 10303-242) is the neutral exchange format for 3D geometry, product structure, and semantic PMI. It is the primary way model-based definitions are shared between different CAD, manufacturing, and inspection systems, and with suppliers.

QIF

The Quality Information Framework (QIF), published internationally as ISO 23952, is the exchange standard for inspection data: measurement plans, characteristics, and results. QIF lets inspection results reference the PMI and model features they verify, which connects MBD to first article inspection evidence.

MIL-STD-31000B

MIL-STD-31000B defines requirements for technical data packages (TDPs) delivered to the U.S. Department of Defense, including model-based TDPs. It builds on ASME Y14.41 and Y14.47 and specifies how 3D product definition data is delivered and controlled for acquisition and sustainment.

Quality and compliance standards

Quality management standards don’t define MBD, but they set the evidence MBD data must provide. AS9100 requires aerospace organizations to control documented information, maintain configuration management, and retain objective evidence of conformity. It does not require drawings, so a released, controlled model dataset can serve as the product definition as long as it meets the same control and record-retention requirements. AS9102 defines first article inspection requirements and forms, which apply under either approach.

Other industries follow the same pattern. ISO 9001 requires control of documented information, IATF 16949 adds automotive-specific requirements including PPAP, and medical device manufacturers follow ISO 13485 and FDA design control requirements. In each case, the question is not whether the definition is a drawing or a model, but whether the released definition, manufacturing records, and inspection results can be shown to connect.

When do 2D drawings still make sense compared to MBD?

The choice is rarely between all drawings and all MBD. Most organizations use MBD where it delivers measurable gains in traceability, inspection efficiency, and digital continuity, while retaining drawings where they continue to serve supplier, contractual, regulatory, or operational requirements.

Supplier capability. Some suppliers lack the software, training, or process maturity to work from a model. If a critical supplier can only work from a drawing, a drawing remains the practical way to communicate requirements to them, at least until that supplier is qualified for MBD.

Internal readiness. Even with the software in place, organizations often keep drawings while engineering, manufacturing, and quality teams build the procedures and skills to author, release, consume, and inspect model-based definitions consistently.

Contractual and regulatory requirements. Some customers, procurement specifications, and regulators still require drawing deliverables. In those cases, the drawing is part of the contractual definition or compliance record, regardless of how engineering works internally.

Long-term archiving. Drawings have traditionally been treated as the safest long-term record. In aerospace, the LOTAR standards (EN/NAS 9300) now define how to archive 3D models with PMI over a product’s full service life, so this reason carries less weight than it used to.

How to make a hybrid MBD and drawing approach work

A hybrid approach uses the model as the primary definition and generates drawings (reduced-dimension drawings, inspection or supplier drawings, or service documentation) only where they’re needed. It works only when the definition states which artifact governs. A derivative drawing should identify the model as authoritative, for example with a note that undimensioned features are defined by the model, and it should be released at the same revision. Without that rule, a hybrid brings back the model-and-drawing synchronization problem that MBD is meant to remove.

How do you transition from 2D drawings to MBD?

Most organizations move to model-based definition in stages: they define what success looks like, prove the approach on a pilot, qualify the people and suppliers who will use the data, and then expand as results justify it.

1. Define Goals and Baseline Metrics

Decide what the transition should improve and measure it before you start. Common measures include drawing creation effort, inspection planning time, revision-related errors, rework, and time spent preparing for first article inspections and configuration audits.

2. Choose a Pilot

Start with a new product, a contained assembly, or a program where traceability, frequent changes, inspection volume, or supplier collaboration offer the clearest gains. Avoid starting with a stable legacy part, which has the least to gain.

3. Set PMI Authoring Standards

Define how dimensions, tolerances, datums, notes, saved views, and model organization will be created, checked, and released, based on ASME Y14.41, ASME Y14.47, or ISO 16792.

4. Decide the Target Definition Level for Each Part

Not every part needs to be model-only. Common levels include:

• Model with full drawing: the model is used for engineering, and the drawing still governs.
• Model with reduced-dimension drawing: the model governs, and the drawing shows only what certain users need.
• Model only: the annotated model is the complete product definition.

Document which artifact governs at each level so there’s never doubt about which one controls.

5. Validate Data Exchange and Qualify Suppliers

Before releasing model-based data, confirm that it arrives intact. Test STEP AP242 and other derivative formats against the master model, using resources such as the CAx Implementor Forum’s recommended practices and NIST’s PMI test models. Then confirm what each supplier can actually do:

• Can they consume semantic PMI, or only graphical PMI?
• Can their inspection systems extract characteristics from the model?
• Which derivative formats will they need?

6. Update Processes and Train Teams

Authoring the model is often easier than changing the processes around it. Release workflows, change management, inspection planning, FAI procedures, supplier requirements, and configuration management procedures all need to recognize the model as the authoritative definition. Engineering, manufacturing, and quality teams need training to author and use it consistently.

7. Expand Based on Results

Compare pilot results with your baseline, refine your standards and procedures, and extend MBD to the programs and suppliers where the gains are clearest.

How does PTC support Model-Based Definition?

Model-based definition works best when authoring, data management, and downstream access are connected. PTC supports each of those stages:

• Authoring in Creo. Engineers apply semantic dimensions, geometric tolerances, datums, notes, and surface finish directly to model geometry, with GD&T syntax checking against ASME Y14.5 and ISO 1101. The Creo GD&T Advisor extension guides and validates tolerancing schemes, and combination states organize PMI into views for downstream users.
• Neutral exchange. Creo exports semantic PMI to STEP AP242 for suppliers and systems that don’t use native Creo data.
• Release and change control in Windchill. Windchill manages the annotated model as the released product definition, with revision control, change management, and effectivity, and makes model annotations available for manufacturing process planning.
• Access in PTC Product View. Suppliers, shop floor, and quality teams can view models and PMI without a CAD license.

Learn more about model-based definition with PTC.