Manufacturing Data Extraction Pipeline

Every order arrives as a package: a fab drawing, a stackup, and the CAD data that describes the board itself. Before anything can be built, someone has to turn that package into structured data — roughly thirty manufacturing spec fields per job, typed into the systems that drive production.

That work fell to quoting engineers, and in practice they read the drawing and the stackup. The CAD data is not something a person reads: Gerber describes copper geometry, not specifications. So the human pass was always working from a subset of what the package actually contains.

It ran about thirty minutes per order, it was tedious enough to invite mistakes, and because it sat at the very front of the process, it set the pace for everything behind it. Throughput was limited by how quickly people could read documents and type.

The obvious move — hand the package to a capable model and let it read — was the one move the environment did not allow. So the interesting problem was never extraction accuracy on its own. It was building something accurate enough to trust, inside a network nothing is allowed to leave.

The pipeline starts where the work actually starts: an order landing in the ERP triggers it. From there it pulls every part of the package — the drawing, the stackup, and the CAD data — including the sources a person was never going to read. Reading more of the package than a human can is the point: the same spec is often stated in more than one place, and disagreement between those places is the most useful signal available.

None of that path is interactive. The order and its package are written to a database, and an intake spooler works the queue one job at a time, continuously — so a week of orders moves through a single box without anyone scheduling anything, and each job has the whole machine while it runs.

Extraction runs against the on-prem vision-language model. Each field comes back with its source, and the readings are cross-validated against each other before anything is written down. Values that agree pass through. Values that disagree are the ones a human should look at, which is a far better use of an engineer than typing values that were never in question.

Then the part that actually bought the time back: the review interface. Most of a fab drawing is irrelevant to a quote — roughly ninety-five percent of it — and a quoting engineer is looking for a specific handful of attributes buried in it. So the original thirty minutes was mostly search, not judgement: reading a long document to find a few values.

Because extraction records where every value came from, the interface can show each extracted value beside its source and point the engineer straight at the callout or line it was read from. The job changes from hunting for values to confirming citations. Thirty minutes of reading became five minutes of checking.

That checking step is deliberate, not residual. At 98.8%, roughly one value in eighty is wrong, and a wrong value on a fab package is expensive. The system was built to make verification fast, not to remove the verifier.

The confirmed result is written to SQL Server as structured data, and a headless spooler renders the XML the CAM system expects. No parallel process to maintain — the data shows up where it always had to be, and the humans moved from transcription to audit.