Fourteen fabrication drawings, every one stamped not to scale, and what they could still prove

The client sent 14 fabrication drawings of the items they build. My assumption was that these were the authoritative record: real dimensions, real geometry, the thing the pricing rules ought to be checked against and eventually the thing a 3D preview could be generated from.

Every one of them is stamped not to scale.

That single stamp invalidates the geometry. The lines in the file do not represent the sizes of the thing. Any tool that measures the drawing gets a number that means nothing. What the drawings actually carry, and the only thing they carry, is a set of annotated measurements written by a draughtsman as text.

Getting the data out at all

Before any of that could be established there was a format problem, and it is worth recording because it shapes what is possible.

All 14 files were in the proprietary binary CAD format, at a recent version. No library in the language the rest of the system is written in reads that format. The libraries that exist read the open interchange format only.

So the pipeline begins with a conversion step performed by an external desktop tool, which needs administrator rights to install and is fundamentally a graphical application that happens to accept a batch invocation. That is now a permanent dependency of any automated extraction: a desktop program on one operating system, invoked from the command line, converting a directory of files before anything can be parsed.

I would not describe that as a solved pipeline. It is a workable one, and knowing that up front changes the estimate for any “just read the CAD files” request by a wide margin. The honest summary is that reading a proprietary CAD format is a procurement decision before it is a coding decision.

Where the real dimensions live

Once converted, the useful content is not the geometry. It is the dimension annotations, and specifically the text override on each one — what the draughtsman typed rather than what the software measured.

Those are imperial inch figures, written the way a person writes them on a shop drawing. Some are plain numbers with an inch mark. Some are mixed fractions. Some are wrapped in formatting markup because the draughtsman wanted a particular text height, so the actual value is buried inside a control sequence rather than sitting in the field.

A parser for that is a parser for human handwriting conventions, not for a data format. It will have a coverage figure rather than a correctness guarantee, and it did: of the 14 drawings, two yielded no dimensions at all, because their measurements were written in a form the parser did not recognise. Probably feet-and-inches, possibly plain numbers with no unit mark, possibly text attached to a leader rather than a dimension entity.

That is the correct outcome to report — two files unparsed, cause suspected, extension needed if those products matter — rather than silently returning fewer dimensions.

The second wrong assumption

I expected to identify features from block references. In a well-built CAD model, a recurring component is a block, inserted repeatedly, and detecting which features an item has is a matter of listing the block insertions.

There were none. Not a single one across the 14 files. Every feature is drawn as raw lines on what is effectively a single layer.

So features cannot be detected structurally at all. They can only be inferred from text — labels and annotations — which is guessing. This is what killed the idea of driving anything automatic from the drawings, and it is why the 3D preview ended up being generated parametrically from quote data instead.

The lesson generalises past CAD. A file format’s capabilities tell you nothing about whether a given file uses them. The format supports blocks, layers and scale. These drawings use none of the three, because they are production shop drawings made by people who need a fabricator to read them, not a data model made by people who expected a program to read them.

What the drawings were genuinely good for

Having established what they could not do, they did do one thing well.

Each drawing was matched to its product type and used to check the definitions of that product’s pricing rules — not the prices, the definitions. Every calculation chain was statically validated: does each step reference only values that already exist at that point, does every identifier resolve to a dimension the system knows, a material slot, or a rate code.

Across every product the 14 drawings mapped to, that check returned zero problems. No broken chains, no unresolvable identifiers.

That is a modest-sounding result and it is a real one. It independently confirms what a separate reconciliation against the source workbook had concluded, using a different route and different inputs. Two unrelated checks agreeing is worth considerably more than either one alone.

The drawings also gave a coverage comparison that nothing else could. For a work table with a sink, the pricing model requires 11 dimension variables. The drawing annotates 5.

That gap is not a defect in either artefact. The drawing describes one item that was actually built, with standard sizes left unstated because the workshop knows them. The model describes every item of that type that could be ordered, so it has to parameterise the optional features and the sizes the workshop would otherwise assume. A record of a built thing and a specification of a sellable thing have different completeness requirements, and confusing them is how you end up believing you can derive a quoting system from a drawings folder.

The small findings that were worth the trip

Four drawings had no confident product-type match, which either means those products are absent from the catalogue under a recognisable name or the naming has diverged. Either way it is a question for a person, not a bug.

And running the comparison surfaced some untidiness in the dimension definitions themselves: a handful of length variables tagged with a count unit rather than a length unit, at least one apparent duplicate pair covering the same measurement under two names, and a rate value sitting in the dimension list where it does not belong.

None of those broke anything. All of them are the kind of thing that eventually confuses whoever maintains the catalogue next, and none of them would have been found by testing prices.

The rule

Before treating any external artefact as a source of truth, read what it says about itself. “Not to scale” on a drawing, like a comment saying a field is unused, is the file telling you which of its contents are load-bearing.

Then ask the narrower question — not what can I generate from this, but what can this prove. A set of drawings that cannot be a dimension source can still independently verify that your calculation definitions are well formed, and that is worth having.