When people hear that ShapeSense uses AI to understand engineering drawings, the first question is usually the same.
"Can't you just fine-tune a vision model on enough drawings?"
Reasonable question. Vision models have become remarkably capable — identifying objects, extracting text, recognising symbols, learning domain-specific patterns from labelled data. Fine-tuning on a new domain is standard practice.
The assumption breaks quickly. And the reason it breaks is more fundamental than most people expect.
A drawing is not an image
An engineering drawing is an engineering language.
A language with grammar — projection standards, GD&T symbols, tolerance notation, revision conventions, datum references. A language with semantics — where a symbol's meaning depends on its spatial relationship to geometry, its interaction with other annotations, and the manufacturing context it implies.
A positional tolerance callout means nothing without its datum reference. A surface finish specification means nothing without knowing the manufacturing process it constrains. A revision note means nothing without understanding what changed and why.
Standard vision models learn to recognise visual patterns. Engineering drawings do not communicate through visual patterns alone. They communicate through a structured system of relationships between geometry, annotation, and manufacturing context.
That is a fundamentally different problem.
The ground truth problem
Fine-tuning requires labelled data. Labelled data requires ground truth. Ground truth requires an agreed definition of what correct looks like.
In engineering drawing understanding, that definition does not exist.
There is no standard drawing format across companies or industries. A GD&T callout at one manufacturer looks different from the same callout at another. Title blocks vary. Layer conventions vary. Projection standards differ between the US, Europe, and Asia. Symbol libraries are not universal.
More fundamentally — there is no agreed definition of what understanding a drawing means. A model that correctly identifies every line, symbol, and dimension on a drawing has not understood the drawing. Understanding requires knowing what each element means for the decisions that depend on it — manufacturing process selection, supplier qualification, cost estimation, inspection planning, design reuse.
Those meanings are not written in the drawing. They exist in the relationship between the drawing and the engineering context that surrounds it.
You cannot label what you cannot first define. And defining correct understanding of an engineering drawing requires deep, specialised domain knowledge that does not yet exist in any standard benchmark or training dataset.
The deterministic problem
There is a third reason standard AI approaches struggle here — one that is less discussed but more fundamental.
Modern AI systems — large language models, vision-language models, generative models — are probabilistic. They produce outputs that are most likely correct given the training data. For most applications this is acceptable. A language model that is right 95% of the time is genuinely useful for writing, summarisation, and general reasoning.
Engineering is deterministic.
A tolerance is either held, or it isn't. A part either fits the assembly, or it doesn't. A supplier either meets the specification or they don't. There is no "probably correct" in manufacturing. There is no acceptable error rate when a misread tolerance changes the manufacturing process, disqualifies a supplier, or causes a part to fail in the field.
This is not a limitation that can be fine-tuned away. It is a fundamental mismatch between how probabilistic models reason and what engineering decisions require.
A model that is 97% accurate at reading engineering drawings is not useful in a manufacturing context. The 3% it gets wrong are not randomly distributed across unimportant details. They are concentrated in precisely the features that matter most — the tolerances that constrain supplier selection, the notes that define special manufacturing requirements, the revision changes that alter downstream decisions.
Engineering AI cannot afford to be approximately right. It must be precisely right — or it must know when it isn't and say so.
This requires a different approach to the problem. Not more training data. Not a larger model. A fundamentally different architecture — designed for deterministic outputs in a domain where the cost of being wrong is not a degraded user experience but a manufacturing defect, a sourcing failure, or a compliance breach.
The connection problem
Even if ground truth were solvable and probabilistic outputs were acceptable — a fourth problem remains.
Engineering knowledge is distributed. A single engineering decision connects information across multiple systems that were never designed to talk to each other — CAD models, PDF drawings, PLM revision histories, ERP supplier records, manufacturing process specifications.
Understanding why a tolerance was specified requires knowing which manufacturing processes are available. Understanding which supplier can hold that tolerance requires knowing the approved vendor list and their historical capability data. Understanding whether a design has been solved before requires connecting the current geometry to decades of prior design decisions.
A model trained on drawings alone — however accurately — cannot access this context. The information it needs to truly understand the drawing lives outside the drawing, in systems that speak different languages and were never designed to connect.
This is the connection problem. And it is as technically significant as the recognition problem, the ground truth problem, and the deterministic problem.
What this actually requires
Building AI that understands engineering drawings requires solving two distinct and equally hard problems simultaneously.
The first is reading the engineering content accurately — geometry, tolerances, annotations, and the relationships between them — with the precision that deterministic decisions require. This is not a problem of scale or model size. It is a problem of architectural design. The system must be built from the ground up for precision, not probability.
The second is connecting that content to engineering context — the enterprise data, manufacturing knowledge, and decision history that gives the drawing its meaning. This is a systems problem that no amount of model training resolves. It requires understanding not just what the drawing says but what it implies for every downstream decision that depends on it.
Neither problem is more important than the other. Neither is a shortcut to the other. Both require serious, purpose-built technical work.
The manufacturing industry is at an early stage of understanding what AI for engineering data actually requires. Most current approaches — applying general-purpose LLMs and vision models to engineering documents — are solving the easy version of the problem. They are building systems that are approximately right in a domain that requires precise answers.
ShapeSense is building something different. Not because the harder path is more interesting — though it is — but because the easier path does not actually solve the problem.
We are still early. But the direction is clear.