When the 3D Model and 2D Drawing Disagree on a Part
Share
A hole can appear in the same location in a 3D model and a 2D drawing while its tolerance or finish requirement exists only on the drawing. The geometry may look consistent on screen, yet the manufacturing package still contains different instructions. That is enough reason to stop the affected decision.
Do not settle a 3D model versus 2D drawing discrepancy by habit. Identify the exact feature, find the order of precedence agreed for that order, obtain a written answer from an authorized source, and release a reconciled set of files. Until those steps are complete, the disputed feature remains open.
Locate the conflicting feature
Compare the files at feature level rather than asking whether the model and drawing “match.” Give each disputed characteristic an identifier that another person can locate in both files: for example, hole H-04, shoulder diameter D-02 or mounting face F-01. Record the view, coordinate, datum reference, note or model selection needed to find it. This prevents a reply about one hole from being applied to every similar hole on the part.
Then transcribe both requirements without interpreting them. Capture nominal size, location, orientation, feature presence, thread, tolerance, surface texture, coating or other relevant instruction. A blank model field does not mean that a drawing requirement is absent, and a drawing view that looks unchanged does not prove that it reflects the current model.
Fictiv lists mismatched overall dimensions, incompatible hole and thread definitions, different hole locations, and features present in only one file as examples of discrepancies in its own model-and-drawing workflow. IronCAD also describes how a broken associative link, a static PDF or DXF export, manual drawing edits, and different file versions can leave a drawing out of sync with its model. These are useful prompts for inspection; they do not establish which file governs your order.
Check the agreed order of precedence
There is no safe universal answer that the 3D model always wins or the 2D drawing always wins. The controlling source may be stated in the purchase order, contract, quality agreement, supplier instructions, quotation notes, drawing title block or a model-based definition plan. Read the actual documents incorporated into the order and identify both the precedence clause and the person or role authorized to resolve an exception.
Platform policies illustrate why this check matters. Fictiv says that, within its process, the supplied model is generally used as the fabrication basis and the drawing is used to inspect additional requirements; it may fail a quote or hold production when a discrepancy is found. Xometry’s page on model, drawing and quote discrepancies describes its service as model-based while also identifying information for which a drawing may supersede model-derived data. Xometry further states that its team seeks clarification and, under its own no-response process, may proceed using the model as the primary reference. Those statements govern the respective services. They do not create a default rule for a purchase order placed with another supplier.
Record the exact source, revision and clause or note that supplies precedence. “Our usual practice” is not equivalent to an incorporated contract term. If the documents do not establish a hierarchy, if two incorporated clauses conflict, or if the hierarchy does not answer the specific feature, keep the feature on hold and ask the designated authority. A buyer, programmer or inspector should not invent precedence from file format, timestamp or apparent level of detail.
A useful order-of-precedence check answers four questions:
- Which documents were incorporated into this order?
- What exact language ranks them or governs discrepancies?
- Does that language cover this characteristic, including drawing-only requirements?
- Who is authorized to approve a deviation or revised requirement?
A file can be newer and still be unreleased. Likewise, identical file bytes or a successful upload can confirm file identity without proving engineering approval. Keep technical authority, file revision and delivery evidence as separate records.
Send a feature-level clarification
Write one answerable question for each affected feature. Include the part number, order or quote reference, feature ID, model value and revision, drawing value and revision, applicable contract source, and the production or inspection activity being held. Ask the authorized respondent to state the approved requirement and the file revisions that will embody it. Avoid a broad message such as “Please confirm the drawing.”
Geometry conflicts
For geometry, state both competing definitions in the same units and reference system. If the model shows one hole diameter while the drawing specifies another, quote both values and identify the hole. If a position differs, include the datums or coordinates used in each representation. If a feature exists in only one file, say whether the open question is to add it, remove it or confirm that one representation intentionally omits it.
Ask for a single disposition that can be verified: the approved value, which files will change, the new revisions, and the effective order or lot boundary. Do not ask the recipient merely to choose “model” or “drawing” when one file contains several unaffected requirements. A feature-level answer limits the decision to the discrepancy actually reviewed.
Consider a hypothetical mounting hole labeled H-04. Model revision M7 shows a 14 mm diameter; drawing revision D5 calls out 12 mm. The contract source says only that discrepancies require written engineering clarification. “Use the latest file” would not resolve the question because it neither identifies the approved value nor establishes whether M7 or D5 was released later. A usable answer would name the diameter, identify the authority and approval record, specify the model and drawing revisions to be issued, and state which order quantity the change covers.
Drawing-only requirements
A model and drawing can agree visually while the drawing carries requirements that are not apparent in nominal solid geometry. Fictiv identifies tolerances, threads and surface finishes among the information commonly supplied through a drawing. Xometry similarly identifies GD&T callouts, tap sizes, inserts, surface roughness and general or specific tolerances as supporting print information in its process. These examples explain why “the model looks right” is not a release criterion. The actual requirement still comes from the documents and precedence agreed for the order.
Clarify drawing-only information with the same discipline used for geometry. Name the surface, feature or note; transcribe the exact requirement; identify the source and revision; and ask whether the requirement remains, changes or is intentionally removed. If a general tolerance block conflicts with a feature-specific tolerance, do not silently select the tighter or looser value. Apply only the hierarchy or exception rule that the approved package actually provides.
The original register below shows how to keep the decision open when information is missing or contradictory. All three rows are hypothetical and are not KTSU production, inspection or customer records.
| Case | Feature ID | Model value | Drawing value | Contract source and question | Approved answer and file revisions | Register status |
|---|---|---|---|---|---|---|
| Complete record | H-04 | Ø14 mm in M7 | Ø12 mm in D5 | PO-EX-24 §4 requires written engineering disposition. Which diameter applies? | Hypothetical approval AR-17 specifies Ø12 mm; model M8 and drawing D6 both implement it. | Ready for review; not automatic engineering approval |
| Missing answer | F-01 | Finish not represented in M3 | Finish note on D4 | PO source recorded; does the note apply to F-01? | Approved answer and reconciled revisions unknown. | Hold — missing information |
| Contradictory release | D-02 | Approved nominal value in M6 | Earlier value remains in D7 | Change approval recorded; do both files implement it? | Approval is known, but M6 and D7 remain inconsistent. | Hold — files conflict with approved answer |
The standalone fillable version uses the same fields and adds an explicit reconciliation check. It can flag missing information and a known file conflict. A “ready for review” result means the record is complete enough to examine; it does not approve the design, authorize manufacture or release product.
Release one reconciled specification package
After the authorized answer is received, update every affected representation and issue one indexed package. The package should identify the part and order, model revision, drawing revision, incorporated specifications, approval or change record, feature-level dispositions, effective quantity or lot boundary, release date and release authority. Preserve the superseded files according to the applicable document-control process, but make the current released set unambiguous to manufacturing and inspection.
Regenerating a drawing can repair a stale derived view when its associative link remains intact. IronCAD’s explanation of an out-of-sync 3D model and 2D working drawing describes forcing an update, regenerating views, checking manually overridden dimensions, or rebuilding and revising a disconnected drawing. That technical action does not decide whether an intentional drawing requirement or model change was correct. The responsible engineering authority still has to approve the reconciled requirement and release the resulting revisions.
Send the indexed package to every affected party and ask for acknowledgement by package and revision, not a generic “received.” Reconcile unstarted, in-process, completed, in-transit and inspected quantities where the change crosses existing work. Each group needs an explicit disposition; the new release should not silently rewrite what governed earlier work. The adjacent article Why Precision CNC Machining Tolerances Matter for Track Rollers – KTSU explains why individual controlled dimensions matter to roller fit and performance.
Release the affected work only when the feature register contains the approved answer, the named file revisions implement that answer, the order boundary is recorded and the supplier has acknowledged the same package. If any value, authority, revision or applicability remains unknown, leave that row open. A clean export is useful evidence of file state; only the approved, reconciled package supplies the basis for manufacture and inspection.