Structuring Ambiguity with AI

A buyer forwards an email thread with a PDF drawing, a STEP model, and a screenshot of a tolerance block from "last time." The subject line says "Need quote today." The attachments have no revision letter in the filename. The title block is half blurred because somebody printed it, scanned it, and reattached it. The estimator opens the drawing, zooms the GD&T feature control frame, checks the thread callout, and then notices the finish note conflicts with a material spec buried down in the notes. The phone call that follows has nothing to do with machining. It is about reconstructing a work package from a pile of artifacts.

This series argues that American manufacturing wins when coordination becomes fast, verifiable, and boring. Paper 14 is about the step that happens before quoting, before scheduling, before anybody programs a toolpath. The claim is simple and falsifiable: in low volume custom work, an automated intake layer that converts the drawing PDF, STEP model, and inbox thread into a structured extraction with explicit unknowns will reduce clarification cycles by at least 30% without increasing NCR rate, compared to manual intake.

I am going to use one term throughout: structured ambiguity. It is a record that contains both what the machine believes it extracted from the print, model, and email, and what it could not resolve, with pointers back to the exact drawing note, title block field, or model feature that triggered each field. The control point for this paper is the same one your quoting desk already uses — the intake gate — but expressed as an artifact: a machine generated extraction sheet attached to the RFQ record, keyed to drawing revision and model hash.

Mechanism: translation with bounded uncertainty

Most "AI for manufacturing" talk jumps straight to automation at the machine tool. I would put the practical leverage upstream, where a drawing, a STEP file, and an email get converted into a set of fields a quoting workflow can actually consume. Document AI has matured into models that treat a PDF drawing as a structured object with layout, tables, and key value pairs rather than flat OCR text, and both Google and Microsoft explicitly position their document systems around preserving layout and extracting structured content like tables and key value pairs.

The mechanism is a two pass translator. Pass one extracts candidate facts from the drawing, model, and line card, then attaches provenance — the exact note region, the tolerance block crop, the thread callout location, the title block string. Pass two hunts for contradictions across artifacts: a material mismatch between a note and a BOM line, a finish note that fights a surface roughness symbol, a model to print discrepancy. When the translator cannot decide, it emits a question instead of an answer, and it tags that question to the exact drawing block or STEP feature that caused it.

That is a disciplined boundary between extraction and decision, not a best effort parse. The way I would draw it, if the translator cannot confidently infer drawing precedence, revision state, or special process requirements, it refuses to pretend. That refusal is the product. It converts ambiguity into a queue of explicit questions tied to the RFQ record, with links back to the PDF region and the STEP feature list.

The control point is a gating rule on the RFQ intake artifact: no quote moves forward until the extraction sheet has either high confidence values for the MVWP fields or a human resolved status for each open question.

What machines can extract reliably today

Start with the drawing PDF. Modern document understanding models are explicitly trained to preserve layout and interpret visually rich documents, including forms, tables, and reading order, which matters enormously when a title block, a tolerance block, and a notes panel are separated by nothing but whitespace. Research models like LayoutLMv3 and Donut are built for this style of document parsing and structured output, and they show strong performance across form understanding and document question answering tasks that look an awful lot like "find the material, finish, and tolerance scheme in a print."

Engineering drawings are not invoices, but the same techniques apply: detect regions, read the text, then emit JSON keyed to the drawing's structure. A 2025 paper on automated parsing of 2D engineering drawings combines oriented box detection with a transformer based document parser, and reports high precision for GD&T extraction and high F1 across categories like title blocks, threads, surface roughness, and notes. That is not "understanding intent" the way a human means it. It is something narrower and still valuable: a real capability to turn a drawing sheet into fields your quoting desk can search, compare, and validate.

Now add line cards and capability PDFs. A line card is a document full of machine lists, tolerances, materials, certifications, and process notes, usually in tables and bullets — which is exactly what commercial document intelligence systems target, extracting structured elements like tables and key value pairs from PDFs and Office files. When a supplier emails you a capability packet, you can pull "CMM present," "AS9100," "5 axis," "max part size," and "materials" into a normalized supplier record, and attach the cropped table cells as evidence.

The control point is a versioned capability extraction artifact: a parsed line card snapshot tied to the supplier record and stamped with the PDF filename, upload time, and an audit link back to the original table cells.

Where it fails, and why the failures are predictable

The first failure mode is rasterized prints and degraded scans. A PDF drawing that is really a scanned image has completely different error properties than a native vector PDF, and it shows up as broken text, skewed dimension strings, and unreadable GD&T symbols. Recent work on raster mechanical drawing digitization frames this as a pipeline problem blending object detection with text recognition, precisely because "just OCR it" does not survive real industrial drawings, and legacy prints least of all.

The second failure mode is semantic conflict rather than recognition. The translator may read the tolerance block perfectly and still be staring at a conflict between a general tolerance note and a feature control frame, or between a drawing note that says "break all edges" and a model full of sharp intersections. The right output there is an exception record that points at both sources and asks, in plain language, which instruction governs. Guessing is the one move that makes it worse.

The third failure mode is the one I underrated at first: missing intent. A drawing can be flawlessly legible and still omit what the shop needs in order to commit to cycle time and an inspection plan — datum scheme clarity for CMM programming, acceptance criteria for surface finish measurement, a special process certification requirement. The machine cannot conjure any of that from pixels, and the STEP file rarely carries it either. This is exactly where structured ambiguity earns its keep, by making the missing intent explicit, early, and attached to the RFQ record.

The control point is an exception taxonomy attached to the extraction sheet, with closure codes like "scan quality," "conflicting notes," and "missing acceptance criteria," where every code has to link to a highlighted drawing region or a model feature ID.

Agents on the exception path, including the inbox and the phone call

Once the translator emits open questions, you need a second capability: routing and follow up. This is where agentic systems matter, not because they are magical but because they execute the boring loop consistently, which humans under load do not. The research shows that systems like ReAct and Toolformer formalize the idea that a language model can interleave reasoning with tool calls, using external tools to gather missing facts rather than hallucinating them.

In manufacturing terms, the "tools" are your RFQ database, your drawing repository, your prior quote history, your supplier capability record, and your email client. A basic agent loop reads the inbox thread, extracts every explicit constraint it can tie to the PDF drawing and the STEP model, then drafts a clarification email containing only the unresolved items, each one anchored to a cropped image of the relevant note, title block line, or GD&T frame. When the buyer replies "same as last time," the agent pulls the prior RFQ record, compares the revision letter and the tolerance block, and asks the one question that actually matters: which revision, and which precedence.

Tool calling and structured outputs are the practical interface between models and your systems of record, because they let you force the output shape, log what the model attempted, and attach receipts to each extracted field. That matters when the stakes are a wrong material cert packet, a mismatched rev letter on the traveler, or an inspection plan built on the wrong datum scheme. The phone call still happens. The difference is that the call is now about a short list of named unknowns instead of an hour spent rediscovering what was already sitting in the drawing.

The control point is an inbox to RFQ linkage artifact: every clarification question gets created as a tracked item on the RFQ record, with a pointer to the source drawing crop or STEP feature, and it closes only on an explicit written reply or an updated revision file.

Implications

If this works, quoting becomes less about hero estimators and more about deterministic intake quality. In the near term, RFQ response time turns into a function of extraction completeness and exception rate rather than estimator availability, because the first pass runs at machine scale and the second pass is a bounded queue. The measurable shift is a drop in clarification email count per RFQ and a drop in revision churn, because contradictions get caught at intake instead of during programming or inspection, where they stop being questions and start being rework.

The second consequence is that supplier matching improves without any new AI magic. Once line cards and capability PDFs are parsed into normalized fields, you can match by machine envelope, material, tolerance band, and cert packet requirements with far fewer false positives. The measurable shift there is a higher quote to award rate for the suppliers who receive the RFQ, because fewer RFQs land on shops that were never going to satisfy the drawing notes or the inspection plan.

The third consequence is cultural, and I think it is the one that changes relationships. When the extraction sheet and the exception list live on the RFQ record, dispute resolution changes shape entirely, because you can point to what was known at quote time, what was unknown, and when it got resolved. That shrinks the surface area for blame and replaces it with a paper trail of artifacts — the drawing rev, the model hash, the closed clarification items.

The control point is the audit packet that ships with the job: a traveler that references the extraction sheet version and includes the closed question list alongside the drawing revision and the required cert packet.

Outro

American manufacturing does not lose because our machinists cannot cut metal. It loses because we pay the coordination tax over and over, on every PDF drawing and every inbox thread. Structured ambiguity is a way to make that tax legible and then compress it with machines, without pretending the machines are infallible. The failure mode I would watch is ambiguity latency, where missing intent sits in an email for days and only surfaces after a toolpath, a fixture plan, or a CMM program is already underway.

The forward hook is that translation is only half the battle. Once ambiguity is structured, you can start pricing uncertainty explicitly and routing work based on the exception profile of a drawing rather than just its geometry. The control point that connects this paper to the next is a revision lock on the RFQ record, where the drawing PDF, STEP model, extraction sheet, and clarification closures all freeze into a single package before the PO is issued.

Questions to Ask

1. For each RFQ record, do we have an extraction sheet that names the drawing revision, model hash, tolerance block, and thread callouts, or are we still relying on an estimator's memory of the PDF drawing?

1. When the drawing note conflicts with the model, do we create a tracked exception tied to a highlighted region of the print, or do we "decide in our head" and hope the traveler reflects it later?

1. What is our current clarification count per RFQ, measured as the number of emails and calls required to resolve missing material spec, finish note, inspection plan, and datum scheme, and how often does that cycle create revision churn?

1. For supplier line cards, do we store structured fields with evidence links to the original table cells and cert packet text, or do we treat the capability PDF as an attachment nobody can query?

1. When a clarification answer arrives, do we update the RFQ package in a revision controlled way, including the drawing PDF and the extraction sheet, or do we let the answer live only in an inbox thread that production never sees?