It started over a tea-time call.
A friend of mine runs a fabrication unit that builds shell-and-tube heat exchangers. He was telling me about his week. Another enquiry, another drawing to prepare, and his one experienced draughtsman already buried. "The funny thing," he said, "is that this new one is almost the same as an exchanger we built last year. Different pressure, thicker shell, two more baffles, new customer. But we'll still redraw the whole thing in CAD."
That conversation became SandurTech RevE. The question was simple to say and much harder to answer: can a machine read an existing drawing well enough to produce the next one?
This article is about the first half of that question, reading. It's also about one decision we made early, before writing a single AI call, which shaped everything that came after.
The data was there. It was just locked.
My friend shared five real drawings, one of each common TEMA type: AES, AEW, BEM, BES and BEU. That gave us fixed tubesheets, floating heads, U-tubes and even a stacked pair with a changeover valve. Eleven A1 sheets in all.
Before trying anything clever, we did the most boring thing possible. We opened each PDF with an open-source library and simply took stock of what was inside. I'm glad we did, because the inventory was humbling:
- Three of the five drawings had no text in them at all. Every letter had been exported as drawn curves. To a human eye, "SA 516 GR.70" is a material specification. To a computer, it was a few hundred tiny shapes with no meaning.
- One page was stored rotated by 90 degrees. It looked perfectly upright on screen, but every coordinate inside it was sideways.
- Even the two "good" drawings, the ones with real text, had stored their bold text as curves.
If you have worked in plants, you'll recognise this feeling. The data exists. People can read it. It's just locked in a format designed entirely for human eyes.
The temptation I nearly gave in to
The obvious design was beautifully simple: send each page image to a powerful vision model, and ask it to return everything as structured data. Blocks, parts list, design pressures, the lot.
I'll be honest. I was tempted. The models are genuinely impressive, and that approach would have given me a working demo in two days. It would also have given me a system that no fabrication shop could trust. When a model is wrong, it's wrong confidently and neatly, in exactly the same format as when it's right.
So we stopped and did something old-fashioned. Before writing a single AI call, we wrote a table. Every step of the job got one row and one verdict: Code, AI, or Both.
The result surprised me. Out of about thirty steps, the AI was genuinely needed for only three kinds of work:
1. Finding regions on a sheet. Looking at a drawing and saying, "the parts list is roughly here, and that's a section view".
2. Reading text from pictures. Transcribing a row whose letters exist only as curves.
3. Judging meaning. Deciding that "baffle type 1" and "baffle type 2" are the same kind of component, or that a number in the design-data table is the shell-side design pressure.
Everything else was ordinary code: rotation, arithmetic, checking that every value really exists on the drawing, building the output files and validating them. That table became the backbone of the project. Whenever someone (usually me) wanted to hand a new job to the AI, we went back to it and asked: is this perception, or is this a fact that can be computed?
What "code decides" looked like in real life
Principles are cheap, so here is what that rule meant in practice.
Rotation was a matrix, not a prompt. On the rotated sheet, every box first landed in the wrong place. It's tempting to believe a smarter model would fix that. It wouldn't. It was a coordinate transform, the kind of thing an engineering student solves on paper. We fixed it once, in a few lines of code, and it has never come back. A model would have got it right most of the time, and in engineering "most of the time" is a polite word for wrong.
The model guesses, the code snaps. Finding blocks is genuinely an AI job, because a drawing has no labels saying "this is the nozzle schedule." So the model looks at each sheet and draws rough boxes. But rough isn't good enough to cut a table cleanly. So code takes each rough edge and moves it onto the real border line that the draughtsman actually drew.
Where two lines are close together and code can't tell which one is right, the model is asked only to choose between real lines. It never invents a position. With the stronger model we reached about 94.5 percent agreement with layouts a person had checked by hand. A cheaper model managed only about 54 percent on the same task. That gap taught us a lot, and it's the subject of Chapter 8.
Don't read what you can copy. Where a drawing has a real text layer, there's no reason to ask an AI to "read" it. Code simply copies the text and places each word in its table cell by position. On the two text-layer drawings, the AI was needed for just seven cells in total, the bold ones.
Arithmetic never goes to the model. The U-tube drawing has a table of 13 bend radii, and the parts list says "262U". Code adds up the table and checks it really comes to 262. It checks that every tube's developed length equals two straight lengths plus π times its bend radius, and that the tie rods add up to four. These checks cost nothing, run in a blink, and passed on all five drawings. No model was asked to do sums.
The day the rule saved us
Early in the project, the results looked suspiciously good. Too good. I've been around long enough to know that when a commissioning test passes perfectly on the first try, you haven't found success yet. You've found a bug you can't see.
When we dug in, we found it. Some context we were passing to the model included notes from our own hand-made reference catalogue, and those notes contained the very values we were asking it to find. The model wasn't reading the drawing at all. It was reading our answer sheet.
What saved us was the rule from the table: every value must be found on the drawing itself, by code. Once we checked for that, the leak was obvious. We removed it and re-ran honestly. Then, to be sure, we ran a "cold" test: one drawing treated as never seen before, with a fresh folder, no saved answers and prompts that didn't borrow wording from our samples. It took one command, about 72 AI calls, roughly half a dollar and fifteen minutes. The parts list came back 230 of 230 fields identical to the checked reference.
What it delivered
- 1,815 of 1,815 parts-list fields correct across five real drawings, after review
- About US$0.32 in AI costs to read a complete drawing
- An engineer reviews only the doubtful items, about half an hour on a large drawing, instead of doing a full manual take-off for at least a day
Three questions I now ask before any AI call
This project left me with a small test I now use everywhere, in drawings, steel plants or anywhere else:
1. Is the answer computable? If a formula, a lookup or a simple parse can produce it, use code.
2. Can code verify what the AI says? If not, read it twice, or show it to a person.
3. What does a wrong answer cost, and who will notice? A wrong chat reply is noticed in seconds. A wrong quantity in a parts list is noticed on the shop floor, weeks later. The higher the cost and the later the discovery, the less the AI should decide alone.
The AI is the eyes. The code is the hands, the calculator and the auditor. Keep them in their own lanes, and you end up with something an engineer is willing to sign.
Next, in Part 2, "One Read Is a Rumour": why we read every drawing twice, and how two imperfect readers turned out to be more trustworthy than one brilliant one.
#IndustrialAI #EngineeringDrawings #AIEngineering #Manufacturing #HeatExchangers #DocumentAI #OCR #Fabrication #SandurTech #ResponsibleAI
Disclaimer
This series introduces SandurTech RevE, a product in development for AI-assisted engineering drawing analysis and generation. Examples reflect our current capabilities and ongoing validation. Outputs should be reviewed by qualified engineers and verified against approved drawings, standards, and project requirements before use.
