Every AI demo you've seen was run on a clean sample. A crisp PDF, one sheet, real text, perfectly upright, written in one language, describing exactly one version of one thing.
Real fabrication drawings are nothing like that. They've been revised for years, exported from different CAD versions, stamped, signed, sometimes partly crossed out, and occasionally written in two languages. As RevE met more real drawings from a working fabrication shop, almost every week brought a new way for a sheet to be "unusual".
I've come to see each of those surprises as a gift. Here are the ones that taught us the most.
Hindi, hiding inside English letters
Some of our drawings carry Hindi text: a title, a note, or a name repeated beside its English version. On screen it looked perfectly normal. To the computer, it was gibberish.
The reason is historical. Many older Hindi fonts store their letters as if they were English characters, and the font simply draws them differently. The text layer says something like a jumble of Latin letters and symbols, while the eye sees clean Devanagari. A reader that trusts the text layer reads nonsense, and an AI shown that text is confidently confused.
RevE now recognises these older fonts and converts the text to proper Unicode Hindi. That mattered for more than reading. It mattered for confidentiality. A customer's name hidden in English but left visible in Hindi isn't hidden at all. So RevE also finds the Hindi "twins" of confidential names, hides them in the protected copy, and replaces them in new drawings, just like their English versions.
Blocks that were crossed out
Revisions often leave their marks. A superseded note or an old table is struck through with a big cross rather than deleted, because the drawing's history matters.
To a reader, a crossed-out block still looks like a block full of perfectly readable values. Left alone, RevE would have read the old table and the new one, then reported a conflict, or worse, used the wrong one.
So RevE now recognises crossed-out blocks and leaves them out of every reading: the parts list, parameters, chat and new drawings. They're still shown on the sheet, because they're part of the record, but they no longer speak.
The same drawing, twice
Some PDFs contain the same set of sheets more than once, for example an earlier issue followed by a later one. A reader that simply reads every page ends up with two parts lists, two design-data tables and two answers to every question.
RevE now detects repeated sheet sets and asks the user which set to read. It's a small question that a person answers in a second, and one that no amount of AI cleverness should answer on its own.
Text running the wrong way
One family of drawings was stored rotated by 270 degrees. It looked upright in any viewer, and reading worked well after the rotation fix described in Part 1.
Then we started writing to those drawings. Every new value RevE wrote in a new design came out sideways. The writing direction had been taken before the page rotation was applied, a one-line mistake affecting every edit on every one of those templates. It's fixed now, and it's a good reminder that reading and writing are two different journeys through the same coordinate system.
Tube counts that don't divide neatly
Tubesheets with pass lanes split the tube field into halves. Tidy code assumes an even split. Real drawings sometimes have an odd tube count, so one half has one more tube than the other. When RevE redraws a pattern, the extra hole now goes where a draughtsperson would put it, rather than vanishing in a rounding step.
A drawing with no details at all
Most of our drawings had a ring of detail views. One didn't. And RevE, which by then expected details, crashed on it.
This is the most humbling category of all: not the strange drawing, but the simple one that breaks an assumption you didn't know you had made. A drawing with no detail views is now read without complaint, and it's in the test set permanently.
What the mess taught us
Looking back, five habits came out of this.
1. Treat every odd drawing as a test case. Each one above is now a permanent check that runs before every release. The test set is built from reality, not from imagination.
2. When the drawing is ambiguous, ask a person. Which sheet set? Is this crossed-out table still valid? These take a person seconds and would take an AI a guess.
3. Never let "unusual" become "silent". The worst outcome isn't a crash. It's quietly reading the wrong table and carrying on.
4. Confidentiality must follow the mess. A name in a second language, an initial in a revision column, a stamp: protection has to reach all of them, or it reaches none.
5. Write down what still isn't covered. Some notes are drawn purely as lines, with no text and nothing OCR can read reliably. RevE leaves those unchanged in new drawings and says so, rather than guessing.
Why this matters for anyone buying AI
If you're evaluating an AI product for engineering documents, here's my one piece of advice: don't test it on the vendor's samples. Test it on your worst drawings. The 20-year-old revision with three stamps. The scanned one. The one in two languages. The one somebody crossed out by hand.
That's where you'll learn what you're actually buying. And if the vendor is any good, that's where they'll learn the most too.
Next, in Part 8: which AI model? Why it turned out to be ten questions, not one.
#IndustrialAI #EngineeringDrawings #Manufacturing #MadeInIndia #RealWorldAI #Fabrication #DocumentAI #SoftwareTesting #Engineering #SandurTech
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.
