Can AI actually read an engineering drawing

The honest answer is that it depends entirely on what arrived, and most demonstrations avoid saying so. An engineering drawing that was born digital and one that was printed, marked in pen and scanned at 200 dpi are 2 different problems, and only one of them is close to solved.

This post is specific about which parts work, which parts fail, and where a human still has to sign. If you are evaluating a tool that claims to read drawings, these are the questions that separate the demo from the inbox. It sits underneath the wider map in what AI does and does not do for quoting.

What a vector PDF gives you without any vision at all

A PDF exported from CAD carries its text and its geometry as data, not as pixels. The dimensions are text objects with coordinates. The lines are paths. The title block fields are strings sitting in known positions.

Reading one of those is parsing rather than recognition, and it is reliable in a way that image work is not. You can pull every dimension, every note and the entire parts list with no model involved and no guessing.

That matters because a good share of incoming work is exactly this. If your customer exports from their CAD system, the file that reaches you is machine-readable already, and any tool that runs vision on it is doing unnecessary work and introducing error.

The first thing worth asking a vendor is whether they check. A tool that treats every PDF as an image because some of them are scans is throwing away the easy half of the problem.

Why feeding a whole scanned sheet to a model fails

A D size drawing scanned and handed to a vision model as one image loses the resolution that the small text needs. The sheet is enormous, the model downsamples it to whatever its input allows, and a 3 millimetre high tolerance callout becomes a smudge.

This is the failure mode that most explains bad extraction results, and it is structural rather than a matter of model quality. The information is present in the file and destroyed on the way in.

Resolution dies at the input.

The approach that works is to detect regions first and read each one separately. Find the title block, the revision table, the notes, the parts list and each view, crop them, and run extraction on each crop at full resolution. A title block at native scale is easy. The same title block as 4 percent of a downsampled sheet is not.

That is also why region detection is the part worth asking about. It is unglamorous, it never appears in a demo, and it is the difference between 70 percent and 95 percent on the same input.

What an engineering drawing still defeats

Ambiguous callouts are the first category and they are not rare. A dimension with a tolerance that could attach to 2 features, a note referencing a detail on another sheet, a datum that is drawn but never used in a GD&T frame. A human resolves these by understanding the part. A model guesses.

Hand annotations are the second. A print marked in pen with a changed dimension, a circled note, or a customer’s handwriting saying use 316 instead is common and hard. The handwriting itself is readable. Knowing that it supersedes the printed value is a judgement about authority rather than about characters.

Revision clouds are the third and they carry a trap. A cloud marks what changed, which means the sheet contains both current and superseded information, and extraction that reads everything equally will confidently return a mix of the 2.

The fourth is anything requiring a tolerance stack-up to interpret. Whether a stated tolerance is achievable in your process, or whether 3 tolerances combine into something nobody can hold, is engineering rather than reading.

Reading is not understanding.

There is a fifth that is worth naming because it defeats people too. Some drawings are simply wrong. A dimension that does not close, a view that contradicts a section, a parts list calling 4 of an item the assembly clearly uses 6 of. The correct output is a flag rather than a value, and a system that always returns a number will always return the wrong one here.

What a sceptic should assume about accuracy claims

Any accuracy figure is meaningless without the population it was measured on. Ninety five percent on clean vector exports and 95 percent on scanned prints with pen marks are different claims by an enormous margin, and vendors rarely say which they measured.

Ask for the breakdown by input type. Ask what counts as correct, because a system that reads a dimension right but attaches it to the wrong feature has extracted the value and lost the meaning.

Ask what happens to the fields it cannot find at all. Silently omitting a tolerance is worse than misreading it, since a missing constraint produces a cheap quote that wins.

Why extraction needs a confidence score and a human

A system that returns a number without saying how sure it is cannot be used for pricing, and this is not a temporary limitation. Extraction on real packages will be wrong sometimes. The question is whether it knows.

Every extracted field should carry a confidence, and everything below a threshold should stop for a person. That turns an unreliable system into a useful one, because a field flagged as uncertain costs 10 seconds to check and a field silently wrong costs a job.

Wrong and confident is the expensive combination.

The economics work out in favour of this. If 90 percent of fields come back clean and 10 percent need checking, an estimator reviews 4 flagged items instead of typing 40, and the takeoff that used to take an hour takes 10 minutes. That is the actual value, and it does not require the last 10 percent to be solved.

What does not work is a system claiming 99 percent accuracy with no per-field confidence. Averages hide exactly the fields you needed flagged, because the hard ones are hard for a reason.

What this means when you are evaluating a tool

Bring your worst package, not their sample. A scanned print with pen marks, a revision cloud and a note referencing another sheet will separate the tools in about 4 minutes.

Ask what happens per field rather than overall. Can it show you which dimensions it is unsure about. Can it show where on the sheet each value came from, so a human can check it without hunting. Provenance and confidence are the 2 features that make extraction usable and neither photographs well.

Ask about the vector case explicitly, because a tool that handles it properly is faster and more accurate on a large share of your inbox and a tool that does not is doing image recognition on data it could have read.

Then judge it against what you actually do today, which is a manual read of the package taking real hours. The bar is not perfection. The bar is faster and no less accurate than an estimator working through 6 files on a Tuesday, with the uncertain parts still landing on a person’s desk.

Extraction is one input to a price rather than the price itself. What the part costs still comes from your record, the way a machined part build-up assembles it, and reading the sheet correctly is what makes that build-up possible rather than what replaces it.