Reading five drawing formats into one BOM

The first time you build a drawing parser you assume the input is one file. Maybe a PDF. Maybe a STEP. You write a parser per format, you get reasonable extraction on each, and you ship. Then you watch a real engineering intake hit the inbox and discover that the unit of work is not a file. It is a bundle.

A representative bundle for a single new part proposal looks like this: a PDF drawing exported from SolidWorks with view callouts and a title block; a STEP file with the 3D geometry and no human-readable annotation; a DWG someone exported in 2014 that has the original detail dimensions; a native CAD file the customer will not let you open without their licence; and an email body where paragraphs two through four contain the actual spec changes the customer cares about, none of which are reflected in the title block.

The job is not to parse any one of these. The job is to reconcile all five into a single typed BOM that downstream procurement and planning can act on without anyone re-keying the part.

A common mistake is treating the five artifacts as five copies of the same information. They are not. Each carries a different slice of the spec, and the reconciler is only as good as your understanding of what each slice actually contains. Five short dives.

A PDF from SolidWorks, Inventor, NX, or Creo carries structured information in fixed regions: the title block (part number, revision, material code, drafter initials, sheet of N), the views with their dimension callouts, the parts list (for assemblies), and the notes block (tolerance standard, finish callouts, surface roughness). It does not carry anything the drafter chose not to draw - finish callouts that live on a separate quality spec, assembly torque values that live in the work instruction, customer-side spec overrides that landed in the cover email.

A PDF intake parser that does not know which CAD package produced the PDF will misread the title block half the time. Title-block layouts vary per package and per template; the right approach is per-package positional grammar against the template, not generic OCR.

STEP carries the 3D boundary representation: surfaces, edges, assembly tree, sometimes part names. It does not carry tolerance callouts, finish, material, or any information the drafter wrote on the drawing rather than modelled into the geometry. You can compute a cylinder's diameter from STEP; you cannot tell from STEP alone whether that cylinder is intended to be a bearing race, an idler pulley, or a spacer.

STEP is most useful as a cross-check. If the drawing PDF says the hub bore is 38 mm and the STEP says 37.8 mm, something is wrong somewhere and the field gets flagged for human review.

DWG/DXF carry 2D drafted geometry, dimensions, and (crucially) layer assignments. Layers encode intent: a layer named HIDDEN contains the construction lines, a layer named DIM contains the dimension entities, a layer named NOTES contains the callouts. The layer scheme is also wildly inconsistent across CAD operators and across decades. a 2014 export from AutoCAD LT will not share layers with a 2024 export from BricsCAD.

We treat legacy DWG as a fallback. When the PDF crop has lost a detail dimension (because the PDF was page-trimmed at export time, which happens), the DWG often still has it. The parser walks the dimension layer and reads the call-out string back.

Native CAD files carry everything: feature tree, parametric dimensions, PMI (product manufacturing information) annotations, configuration variants, assembly mates. They are also licence-gated. Most contract manufacturers will not install a $5k/seat licence per CAD package on their intake desk, and most customers will not grant view-only access to their full feature tree.

The honest posture is that native CAD is a request-only fallback. When the bundle is missing a critical dimension and the customer has shared the native file, you ask for the dimension by name and the customer's engineer answers out of band. We do not try to parse native files in the general case.

Email is where the spec overrides land. "Please use A325 bolts on this rev, not A307" in paragraph three is a first-class spec change. So is "qty 4 per assembly, not 6 as shown on the parts list. the parts list is from the old rev." So is "ignore the finish note in the title block; per our QA spec PMR-QA-118, this surface is electroless nickel, not zinc."

Treating the email body as a natural-language source. with a per-customer rule pack that knows what kinds of overrides are common. is what separates a usable reconciler from one that silently ships the title-block defaults and lets the customer's spec changes fall through.^[1]

The wrong shape. and we have built this shape and regretted it. is to convert every artifact into a common intermediate and then parse that. It sounds principled. It loses fidelity at every conversion step.

PDF-to-text loses the positional grammar of the title block. STEP-to-mesh loses the parametric named features. DWG-to-PDF collapses the layer information. Email-to-prose strips the quoted-reply structure that often disambiguates which override replaces which prior value. By the time you have unified everything into a single intermediate, you have thrown away the per-format signal that made each artifact worth parsing in the first place.

The shape that worked was the opposite: keep each parser format-native, let it produce a candidate field set in the shared schema, and let the reconciler do the merging. The reconciler can ask each parser, by name, "what is your reading of material_grade and how confident are you?" and apply explicit rules.

Once each artifact has been parsed to a candidate field set, you have five competing readings of the same part. The reconciler decides which one wins for each field, and on what evidence.

The rules are not exotic. They are mostly:

• Title-block fields (part number, revision, material) come from the most-recent PDF unless the email body explicitly overrides them.
• Quantities come from the parts list region of the PDF, with the email body as an explicit override path when the words "qty" / "quantity" / a numeric followed by "ea" appear in the same sentence as a known component.
• Material grade callouts come from the drawing first, the email second, the STEP never. If the drawing and the email disagree, the field gets marked for human review.
• Dimensions come from the drawing PDF first; the legacy DWG is consulted only when the drawing crop is missing detail. STEP geometry is used as a sanity check, not a source.
• New parts (not yet in the item master) get flagged as new; matched parts get flagged as matched; parts whose attributes drifted from the matched master get flagged as review.

These rules are unglamorous. They are also where most of the engineering value lives, because they are the rules the senior intake engineer at the customer was already running in their head. Writing them down makes them inspectable.

The reconciled BOM does not get written to the ERP. It gets drafted into an intake proposal that surfaces in a queue, with per-row provenance for every field. Every cell shows which source artifact it came from. Every review flag is justified with the conflicting readings side by side.

The intake engineer reviews the proposal. They override the two or three fields the reconciler got wrong, accept the rest, and the BOM lands in the ERP as a new item or a revision bump. The work the engineer used to do. opening five files, comparing them in three windows, cross-checking the email - collapses into a screen.

A list of the specific reconciliation traps that ate hours of intake-engineer time before we wrote rules for them. None of these are theoretical. All of them have shipped bad data into a production BOM at least once before the rule existed.

One operational lesson worth recording: the cost driver is not the per-format parser quality. The cost driver is the surface area of conventions per customer.

One shop exports drawings landscape, with the title block on the right; the next exports portrait with the title block at the bottom. One shop puts revision in cell K2; the next puts it in the filename. One shop writes material grade in plain English; the next writes ASTM codes only. These are not parser bugs. These are conventions, and the ingestion pipeline has to learn them per customer.

The shape that works in production is a small per-customer conventions pack. a few dozen rules. sitting above a shared extractor library. The pack is editable by the intake engineer when a new convention surfaces. Most customer-specific surprises are absorbed in the pack within a week of going live.

Two approaches we have explicitly abandoned, because they looked clever but did not survive contact with real bundles.

First, single-call LLM extraction over the entire bundle. It works for the happy path, fails silently for the rest, and gives no provenance. The bundle is not a prose document. It is a structured artifact with known regions per format, and treating it as prose throws away most of the signal.

Second, building a unified intermediate representation for every drawing format before reconciliation. Sounds principled. In practice it adds an extra translation step that loses fidelity, and the per-format extractors are easier to debug when they speak the format's native vocabulary.

What survived is a small per-format extractor library, an opinionated reconciler with explicit per-field rules, and a surface that always returns a proposal for human review. The interesting engineering is in the reconciler. The interesting product is the proposal.