The drawing is not the problem

The Drawing Is Not the Problem

Model-Based Definition gets the diagnosis right and the prescription wrong.

For those unfamiliar with the term, Model-Based Definition (MBD) is the practice of embedding all product manufacturing information (PMI), including dimensions, tolerances, surface finishes, material specifications, and geometric dimensioning and tolerancing (GD&T), directly into the 3D CAD model rather than communicating it through traditional 2D engineering drawings. The promise is a single, authoritative digital artifact that serves every stakeholder in the product lifecycle: design, manufacturing, quality, and procurement all reading from the same source, with no possibility of the drawing saying one thing and the model saying another.

This is a valid concern. Engineering drawings can drift out of sync with CAD models. Maintaining two parallel representations of the same design intent creates risk for error, slows engineering change cycles, and frustrates any attempt at a coherent digital thread. These are real problems, and the appeal of a single source of truth, the annotated 3D model, is both logical and genuine.

But MBD's prescription rests on a fundamental misreading of what a drawing actually is. Its advocates treat the drawing as a data container: a vessel for dimensions, tolerances, and notes that could just as well live on a 3D model. Strip away the paper-era format, migrate the PMI to the solid geometry where it semantically belongs, and you have a cleaner, more tractable data architecture. From the vantage point of PLM strategy and enterprise data management, this reasoning is airtight.

– "It is also wrong. Not in its logic, but in its premise."

A drawing is not a data container. It is an editorial artifact. A skilled detailer making a drawing is performing information design: selecting views that expose the features relevant to manufacturing and inspection, arranging callouts so the eye follows a logical sequence, choosing section cuts that reveal internal geometry without overwhelming the reader, and, critically, deciding what to leave out. A drawing that calls out everything communicates nothing. It is the act of curation that makes an engineering drawing useful.

This is something a 3D model viewer cannot replicate, no matter how much PMI is embedded in the geometry. A model viewer is an exploration tool. The user rotates, zooms, toggles annotation layers, and hunts for the information they need. A drawing is the opposite: it is a pre-digested, carefully composed visual argument about how a part should be made and verified. Exploration serves understanding. Drawings serve execution. These are fundamentally different interaction paradigms, and conflating them is where MBD goes astray.

The practical consequences bear this out. Companies that adopt MBD rarely eliminate drawings. They shift from drawings-as-master to drawings-as-derived, generating 2D views from the annotated model. But "derived" implies automation that does not exist in any meaningful sense. Projecting PMI onto a view plane produces illegible clutter: overlapping leaders, stacked dimension text, GD&T frames obscuring geometry. A human must still intervene to arrange every view into something a manufacturing engineer or a shop floor operator can read at a glance. The editorial labor remains; it simply moves later in the workflow. And when an ECO changes the model, the carefully arranged derived drawing is scrambled, and the layout work begins again.

Meanwhile, the single-source-of-truth benefit erodes the moment the data crosses an organizational boundary. An OEM may standardize on MBD internally, but their supply chain (the job shops, the contract manufacturers, the overseas vendors) consumes drawings. These suppliers are not investing in NX or Creo seats to interpret semantic PMI on a solid model. So the OEM maintains both representations anyway: the annotated model for internal use and the drawing for external communication. The coordination cost that MBD was supposed to eliminate is not eliminated. It is doubled.

It is telling that ASME Y14.41, the standard that governs MBD practice, includes provisions for "saved views": frozen, 2D-like perspectives of the model with curated annotation visibility. This is the standard quietly conceding the point. Even in a model-based world, you still need composed views. We still need someone to decide what the reader should see, from which angle, with which annotations visible. We still need the drawing, in spirit if not in name.

None of this means that associating PMI with 3D geometry is without value. It is a sound data management practice. But it is not a replacement for the drawing as a communication medium. Framing it as a replacement and process simplification only reveals a blind spot that traces back to where MBD advocacy originates within an organization.

MBD initiatives are almost never driven by mechanical engineering departments or by operators on the shop floor. They are championed by IT leadership, PLM strategists, and digital transformation consultants: people whose daily work is data architecture, system integration, and lifecycle traceability. From their perspective, the drawing is a legacy format that resists programmatic query, breaks the digital thread, and introduces version control risk. These are legitimate concerns. But they are concerns about data governance, not about manufacturing communication. The people who actually produce and consume drawings (detailers, manufacturing engineers, machinists, quality inspectors) are rarely the ones calling for their elimination. When MBD is imposed on these practitioners from above, the result is predictable: grudging compliance, parallel shadow processes, and a persistent sense that something valuable has been lost in the name of architectural IT centralization.

This disconnect matters. The people who resist MBD are not technophobes clinging to paper-era habits. They are practitioners who understand, from daily experience, that a well-made drawing does something a 3D model does not: it tells you exactly what you need to know, and nothing more.

The drawing is not the problem. It is, when done well, the solution. The real problem is keeping it in sync with the model, and that is an automation challenge, not an argument for abolition.