In brief
A dimensioned drawing is not a letter or a contract. It is a dense technical object: dimensions, tolerances, geometric-tolerancing symbols, datum reference frames, all drawn around a part rather than laid out in lines of text. A general-purpose OCR can read a paragraph; it does not know that a "12.7" followed by a "±0.05" forms a dimension with a minimum and a maximum.
The real danger is not that a poorly built tool makes a loud mistake. It is that it loses data silently: a skipped dimension, a truncated page, a value never read — and no one sees it before the customer does. What separates reliable extraction from a gimmick is not the power of the model. It is the trade-specific software that frames it.
A dimensioned drawing is not text
When people hear "OCR," most imagine a scanner that turns a page into editable text. An invoice, a contract, an administrative form. In those cases the information is linear: it reads left to right, top to bottom, and the layout helps you understand it.
A technical drawing works the other way around. The information is not aligned: it orbits the part. A dimension is placed where it applies, often at an angle, sometimes vertically, tied to an edge by a leader line. A single drawing mixes dimensions in millimetres, imperial fractions, angles in degrees-minutes-seconds, standardized fits (an H7, a g6), unilateral callouts of the "X MAX" kind. And on top of all that, a grammar of its own: geometric tolerancing.
Geometric tolerancing — GD&T, in the trade — is about fifteen standardized symbols (flatness, cylindricity, parallelism, position, and so on) that govern the geometry of the part beyond its plain dimensions. To a machinist, those symbols matter as much as the numbers. To a general-purpose OCR, they are strange drawings it does not even try to interpret, because it was never built for that.
Here is the first misunderstanding. We think we are dealing with a reading problem. We are in fact dealing with a problem of trade understanding. Reading "12.7 ±0.05" is useless if the tool does not know it just came across a nominal dimension of 12.7 mm, with a symmetric tolerance, and therefore a minimum of 12.65 and a maximum of 12.75. That little bit of arithmetic, a shop owner does in their head. A general-purpose OCR does not do it at all: it has no idea what a tolerance is.
We think we are dealing with a reading problem. We are in fact dealing with a problem of trade understanding.
What a generic tool does not see
Take a concrete case. A well-regarded machine shop in the Sorel region makes precision parts and must deliver, with every order, a dimensional inspection report: proof that each dimension meets the drawing. In the past, an inspector manually read the dozens of dimensions on a drawing, copied them one by one into a spreadsheet, calculated the mins and maxes by hand, then entered the measurements. Painstaking, repetitive work, and by its nature exposed to transcription error.
The idea of automating the reading of the drawing is obvious. Except that a generic tool, turned loose on that same drawing, fails in several places at once, and not where you would expect.
It confuses dimensions with decorative annotations — a revision number, a title block, a manufacturing note. It flattens a stack of tolerances into a single value. It ignores GD&T symbols because it does not recognize them as text. It reads "ø" as a "0" or an "O." It loses the slanted dimensions, the ones that are not horizontal. And above all, on a dense drawing, it stops: it handles the top of the drawing, where the information is clear, and gives up on the bottom, where the dimensions crowd together.
None of these failures is spectacular. Taken one at a time, they look harmless. Strung together, they produce an incomplete inspection report — and an incomplete inspection report, in manufacturing, is not a typo. It is a nonconforming deliverable.
The real danger: silent loss
We have to distinguish two ways for software to be wrong. There is the loud error: the tool displays an obviously absurd value, the inspector sees it, corrects it, and everyone moves on. It is annoying, but it is healthy — the system flags its uncertainty, the human decides.
And there is the silent error: the tool does not read a dimension, and says nothing. It does not show it in red, does not mark it "to verify," does not count it as missing. It simply does not exist in the table. On screen, everything looks complete. This is the kind of failure that costs you, because it stays invisible until someone else — the customer, the auditor — discovers it in your place.
I have seen this mechanism up close. In an earlier version of an extraction tool I was building, a technical ceiling limited the number of rows processed. On a short report, you saw nothing. But a twelve-page scan, with hundreds of dimensions, went past that ceiling — and came back with zero values. No error. No warning. An empty table, politely. The tool "worked"; it just lost everything, without saying so.
The lesson stayed with me, because it is counter-intuitive. We always watch for the errors we can see. It is the ones we cannot see that make an inspection fail. Well-built trade-specific software is judged first on this: its ability to never lose data silently.
Why the software frame changes everything
Here I have to say something plainly, because it cuts against the prevailing talk: the artificial-intelligence model that "reads" the drawing is not the hero of the story. The same model, on its own, produces exactly the failures described above. What makes it reliable is everything we build around it.
In concrete terms, well-designed trade-specific software does at least three things that AI alone does not.
It breaks the work up so nothing gets dropped. Rather than asking the AI to swallow a dense page in one go — the moment it "checks out" and abandons the bottom — we cut each page into bands, process each band, then reassemble. The dimension in the lower-right corner has as much chance of being read as the one at the top. That is an engineering decision, not a capability of the model. This banding counts double on large formats: a drawing delivered in D or E size, or a set of several pages, often arrives as a very high-resolution scan. Shrunk to fit in one block, such a drawing becomes unreadable — the small figures blur, the tight dimensions merge. Processed band by band, at full resolution, page after page, every zone keeps its sharpness and nothing is sacrificed to fit the whole drawing into a single read.
It ties the reading to the trade through deterministic rules. Once a dimension is read, it is not the AI that guesses which row of the report it corresponds to, nor that invents its min and max. It is strict, predictable, verifiable code: parsing the tolerances, computing the limits, recognizing the standardized GD&T symbols. We let the AI do what it does best — recognize what is written — and hand the rest to rules we can audit. We never let the AI "guess" what an exact calculation can establish.
It makes uncertainty visible. When the reading of a value is doubtful, a good tool does not pass it off as certain. It highlights it, sets it aside, forces a human re-read. Uncertainty becomes displayed information, not a buried risk. It is exactly the opposite of silent loss.
The difference between a general-purpose OCR and specialized extraction is therefore not "a better brain." It is a brain that is framed. Without that frame, the AI is a convincing stage set that collapses on the first complex drawing. With it, the AI takes on the repetitive part of the work — reading, transcribing, calculating — and leaves the human the part that is theirs: judging, measuring, signing.
The AI model is not the hero of the story. What makes it reliable is everything we build around it.
What this changes for release of products
You might think all of this stays a matter of internal technique. That would be a mistake, because the reliability of the extraction touches directly on an obligation in the standard.
ISO 9001 governs the release of products and services in clause 8.6: a part is released to the customer only after verifying that the criteria have been met, and while keeping evidence of that verification. The dimensional inspection report is that evidence. It is what attests that each dimension was checked and judged conforming.
So what happens if the tool that produces that report loses dimensions silently? The evidence lies without anyone knowing. The table looks complete, it is not in reality, and a part is released on the strength of an incomplete verification. The problem is no longer technical: it sits at the heart of conformity. An extraction tool is not just a time-saver for the inspector — it is a link in the chain of evidence that authorizes shipment.
That is why I judge extraction software on its rigour before I judge it on its speed. A fast tool that loses data quietly is more dangerous than a spreadsheet kept carefully by hand. And let us be honest: no tool reads every drawing perfectly. A stained, creased, crookedly scanned or poor-quality drawing will give any model trouble — machine vision has its limits, and pretending otherwise would be a lie. Reliability therefore does not come from a perfect, hundred-percent reading: it comes from the tool's ability to flag what it is unsure of, rather than pass it off as read.
The right questions to ask a tool
You do not need to be a software engineer to evaluate a drawing-extraction tool. You just need to ask the right questions — the ones that separate a real trade tool from an OCR dressed up for the occasion.
| The question to ask | What a good answer reveals |
|---|---|
| How do you know no dimension was missed? | Does the tool count what it could not read, or make the missing item disappear? |
| What do you do with a doubtful value? | Is the uncertainty displayed, or drowned in the batch? |
| Do you read geometric-tolerancing symbols? | Does the tool understand the language of the drawing, or only its numbers? |
| What happens on a very dense, multi-page drawing? | Is there an invisible ceiling that makes the tool check out? |
| Who calculates the tolerances: the model or a verifiable rule? | Does the trade logic rest on a guess or on auditable code? |
If the answers stay vague, be wary. A vendor who touts the power of their AI without ever talking about what frames it is selling you the stage set, not the structure. And in manufacturing, it is the structure that stands up at the audit.
In closing: who verifies that nothing was lost?
A dimensioned drawing is one of the richest and most demanding documents a shop handles. Reading it halfway is worse than not reading it at all, because half a report looks like a complete report. That is precisely the trap generic tools cannot avoid: they are excellent at prose, helpless in front of geometry, and dangerous when they fail without saying so.
The real question, then, is not "which AI reads a drawing best." It is: which software makes visible what it missed or misread rather than hiding it, highlights what it is unsure of, and leaves the human to judge and sign what the machine has prepared? Specialized extraction is not a smarter OCR. It is an OCR put to the service of a trade discipline.
One open question remains, one I still ask myself with each new type of drawing: how far can we trust an automatic reading before the human check itself becomes, in turn, a mere formality we end up skipping? The answer, I believe, lies in the word "framed." Remove the frame, and trust becomes a bet. Keep it, and trust becomes proof.
The principles described in this article are the ones that guided the development of Asterion Solutions, a suite of trade-specific software built for manufacturing SMEs that want to structure their quality without multiplying administrative tasks.