ARTICLE
Can GPT Review Engineering Drawings and Perform Quality Control?
Large language models can read a drawing and describe what they see. Reviewing it for compliance and dimensional accuracy is a different task, and the two get conflated more often than they should.
The question behind the question
The question is usually asked after someone has watched a general-purpose language model summarize a specification, answer a question about a code clause, or describe what is shown in an uploaded image, and the leap to whether it can check a set of drawings feels natural. It is worth separating two different things the question can mean, because the honest answer is different for each.
Reviewing a drawing, in the loose sense, means looking at it and producing a comment: what it appears to show, whether something looks unusual, a plain-language summary of a dense sheet. Performing quality control means something narrower and more demanding: applying a defined standard to the drawing's actual content, exhaustively and repeatably, in a way that someone can be held accountable for and that produces the same answer if run twice. A tool can be genuinely useful at the first without being remotely adequate for the second, and most of the disappointment in this area comes from expecting the second from something built for the first.
What large language models are genuinely good at
Applied honestly, a large language model brings real strengths to engineering documentation. It reads a long specification and answers a specific question about it faster than a person paging through a PDF. It compares the language of two documents — a specification and a schedule of accepted variations, for instance — and surfaces places where the wording looks inconsistent, for a person to then verify. It converts a dense, jargon-heavy note into a plain-language summary a project manager can act on without reading the original. It can hold a natural-language conversation about a drawing set's content, which is a genuinely new capability compared with keyword search across a folder of files.
What these strengths have in common is that they operate on language and pattern, not on geometry or numerical proof. A model that reads a general note describing a code requirement and flags a drawing that appears to contradict it in words is doing something real and useful. That is different from confirming, with certainty, that a dimension chain on that drawing actually closes.
Where it falls short of quality control
The shortfall shows up in exactly the areas quality control depends on. Dimensional and geometric precision is not what these models are built for: reading a scaled dimension correctly, confirming that a section cut matches its plan, or verifying that a bar spacing satisfies a numeric code minimum requires exact, deterministic computation, not pattern recognition over an image, and a model asked to do it can produce a plausible-looking answer that is simply wrong. That failure mode — a confident, fluent, incorrect answer — is more dangerous in this context than an honest admission of uncertainty, because it looks exactly like a correct one until someone downstream trusts it.
There is also no inherent determinism: the same drawing put through the same general-purpose model twice is not guaranteed to produce the same finding twice, which is disqualifying for a process that has to be repeatable and defensible after the fact. And a language model, however capable, cannot be the accountable party. Quality control that matters is signed by a named, qualified person who can be asked to justify the decision. A model can inform that judgment. It cannot hold it.
Deterministic checks and language models are not the same tool
Confusing these two is where most of the disappointment comes from. A deterministic, rule-based check — the kind that confirms every bar mark exists in its schedule, that a dimension chain closes, that cover satisfies the exposure class stated in the specification — has one correct answer and produces it exhaustively, every time, on every sheet. That is a geometry and data problem, and it is solved by software built to compute an exact answer against a model or a structured dataset, not by a model built to predict plausible next words.
A language model earns its place somewhere else in the same process: reading unstructured text, flagging a note that appears to contradict a specification, summarizing what changed between two revisions in plain language, answering a question about where a requirement is documented. Asked to do the first job, a language model is the wrong tool even when it produces an answer that sounds right. Asked to do the second, a deterministic geometric checker has nothing to say, because there is no text to reason about. A quality control process that understands the difference uses both, each for what it is actually built to do, rather than expecting either one to cover the whole job on its own.
What responsible use actually looks like
A defensible process treats an AI-assisted observation as a lead, not a conclusion. If a language model flags that a note appears to contradict a specification, that is a prompt for a person to open both documents and confirm it — valuable because it points attention at the right page faster than reading the whole set would, not because the flag itself is the finding. Deterministic checks, by contrast, can be trusted to run exhaustively and automatically precisely because they are computing an exact answer rather than predicting a likely one, which is why they belong earlier in the process and at higher volume.
What should not change, regardless of which tool touched a drawing first, is the last step: a qualified engineer reviews the package and signs it, accountable by name for the judgment involved. Automation — deterministic checking and, where it is genuinely suited to the task, AI-assisted review — changes how much of the repetitive and pattern-matching work reaches that engineer already resolved. It does not change who is responsible for the answer.
The honest answer
The honest answer is neither the confident yes nor the dismissive no that the question usually gets. A general-purpose language model can genuinely assist a quality control process — reading dense text quickly, flagging inconsistencies in wording, making a drawing set searchable in plain language — and none of that should be dismissed because it falls short of the whole job. What it cannot do is replace the deterministic, exhaustive, rule-based checking that dimensional and code compliance actually require, and it cannot be the accountable party that signs a package. The projects that get the most value from this generation of tools are the ones that use each part of a quality control process for what it is actually good at, and keep a qualified engineer's judgment where judgment has always belonged.