Can AI read an engineering drawing for a quote?

Reading or drawing: which question are you asking?

Type ‘AI engineering drawing’ into a search bar and most of what comes back is software that produces drawings, built for the customer's engineering department. This page is about the shop that receives that drawing with a request for quote, and what software can prepare from it for the estimate.

Drawing reading is about requirements: material, dimensions with their tolerances, surface roughness, finishing and threads. Those requirements decide how many setups a part needs, which tools, how long inspection takes and what goes out to a subcontractor. A misread requirement becomes a mistake in the cost price.

Reading is one of several places where AI touches the estimate. For the wider picture, see what AI means for the modern precision machine shop.

What is ready after reading?

After reading, each part has a list of values waiting. Every value is a proposal: it came from the PDF drawing and only counts once someone confirms it. That way nobody mistakes a value that was read for one that was checked.

The table shows, for each drawing requirement, what is set out as a proposal and what a person still checks. For the tolerance classes themselves, see general tolerance under ISO 2768.

Features in the model, requirements on the drawing

Two jobs often get mixed up. Feature recognition points out in the STEP model what has to be made, such as holes and pockets. Reading the PDF drawing picks up what that shape has to meet, such as a tolerance or a thread. The model holds what gets made; the drawing holds how well.

So keep features, requirements and operations apart. A cover plate might have twelve holes, four of them threaded. The holes are features from the model, the threads are a requirement from the drawing, and drilling and tapping are operations that each get their own time in the estimate. Mix the three up and you count a hole twice or lose a thread.

That only works once the model and the drawing of the same part sit together. Model and drawing pairing usually goes by file name; where there is doubt, the choice belongs to a person, not to the software. What to do when model and drawing disagree is covered in the checklist for a complete request for quote.

How do you know nothing was missed?

Only by going through the drawing yourself. A proposal is a starting point: it sets out what was found and says nothing about what was not. Software that promises everything is in there promises more than a drawing allows.

When you do find something, correcting has to be cheap: adding a missed thread or fixing a misread roughness value, with a note if you want to leave one. When correcting is a chore, people end up accepting the value that was read.

Where things get missed is predictable, though. Go through these points on every part before you confirm the proposals.

• Notes outside the title block, such as a finishing instruction next to a single view.
• A general tolerance that clashes with a dimension carrying its own tolerance.
• A thread that only shows in a section or a detail view.
• A revision cloud that changes a dimension while the revision in the title block stayed the same.

Why does software read one drawing better than another?

Every customer draws differently. One puts the material in the title block, another in a note. Software built from examples does well on what resembles those examples, and less well on what does not.

In an April 2026 report on robotisation, TNO notes that in practice it can be hard to feed a data-driven AI model every situation that can occur, because there is a lot of variation and uncertainty. The report is about robots, but the drawings reaching a subcontract machine shop share that character: plenty of variation, little repetition.

Fraunhofer IPT made a related point from the data side in 2021, in a white paper on AI in one-off and small-batch production: the relevant data are mostly not available in sufficient quantity and quality, and the infrastructure to process them is missing. A shop making mostly one-offs and small batches rarely has a large stack of similar drawings to tune software on.

That is why confirmation stays with a person: the next drawing can always look different from the last.

Who confirms what the software proposes?

The manufacturing engineer or the cost engineer: whoever has to stand behind the cost price. Confirm and correct comes down to one decision per value: accept, change, or go back to the customer. That decision should carry a name and a time, so a colleague can later see who settled the roughness on that face.

Record the reason too. A note such as ‘customer confirmed by email: clear anodise’ helps more on a repeat order than a bare correction. When a new revision comes in, set the new proposals beside what was confirmed last time.

This is where the usual way of working falls short. An ERP stores the amount on the last quote, not the decision behind it; the rest lives in a spreadsheet or in one cost engineer's head. When someone carries the old price over to a new revision while a revision cloud tightened a fit, the shop pays for the extra setup or measurement out of its margin.

Putting a customer drawing into software also raises the question of where it ends up. What to ask a vendor about that is in what to ask an AI vendor about customer drawings.