Industrialist Paper No. 14

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, and the title block is half blurred because somebody printed, scanned, and reattached it. The shop estimator opens the drawing, zooms the GD&T feature control frame, checks the thread callout, then realizes the finish note conflicts with a material spec buried in the notes. The phone call that follows is not about machining, it is about reconstructing the 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, scheduling, or programming 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 will use one term: 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 to automation at the machine tool. The practical leverage is upstream, where a drawing, a STEP file, and an email are converted into a set of fields that 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, such as the exact note region, the tolerance block crop, the thread callout location, or the title block string. Pass two checks for contradictions across artifacts, such as a material mismatch between a note and a BOM line, a finish note that conflicts with a surface roughness symbol, or a model to print discrepancy. When the translator cannot decide, it emits a question instead of an answer, and it tags the question to the exact drawing block or STEP feature that caused it.

This is not a “best effort” parse. It is a disciplined boundary between extraction and decision. If the translator cannot confidently infer drawing precedence, revision state, or special process requirements, it refuses to pretend. That refusal is the product: it turns 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 when a title block, tolerance block, and notes panel are separated by 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 a 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” in the human sense, but it is 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 with machine lists, tolerances, materials, certifications, and process notes, often in tables and bullets. This 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 a capability packet, you can extract “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 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 different error properties than a native vector PDF, and the difference 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 that blends object detection with text recognition, precisely because “just OCR it” does not survive real industrial drawings, especially legacy prints. 

The second failure mode is semantic conflict, not recognition. The translator may read the tolerance block correctly and still face a conflict between a general tolerance note and a feature control frame, or between the drawing note “break all edges” and a model that contains sharp intersections. In those cases, the right output is not a guessed answer. The right output is an exception record that points to both sources and asks, in plain language, which instruction governs.

The third failure mode is missing intent. A drawing can be perfectly legible and still omit what the shop needs to commit to cycle time and inspection plan, such as datum scheme clarity for CMM programming, acceptance criteria for surface finish measurement, or a special process certification requirement. The machine cannot conjure that from pixels, and the STEP file rarely carries it. This is where structured ambiguity matters: it makes 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,” “missing acceptance criteria,” and each code must 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 can execute the boring loop consistently. 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 all explicit constraints it can tie to the PDF drawing and the STEP model, then drafts a clarification email that contains 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 with “same as last time,” the agent can pull the prior RFQ record, compare the revision letter and the tolerance block, and ask the one question that actually matters, which revision and which precedence apply.

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, but the point is that the call is now about a short list of named unknowns, not an hour of rediscovering what was already in the drawing.

The control point is an inbox to RFQ linkage artifact: every clarification question must be created as a tracked item on the RFQ record, with a pointer to the source drawing crop or STEP feature, and closed only by 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. The near term consequence is that RFQ response time becomes a function of extraction completeness and exception rate, not estimator availability, because the first pass is 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 are detected at intake rather than during programming or inspection, where they become rework.

The second consequence is that supplier matching improves without 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 fewer false positives. The measurable shift is a higher quote to award rate for suppliers who receive the RFQ, because fewer RFQs are routed to shops that cannot satisfy the drawing notes or inspection plan.

The third consequence is cultural. When the extraction sheet and the exception list are attached to the RFQ record, dispute resolution changes shape, because you can point to what was known at quote time, what was unknown, and when it was resolved. That reduces the surface area for blame and replaces it with a paper trail of artifacts, including the drawing rev, the model hash, and 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 required cert packet.

Outro

American manufacturing does not lose because our machinists cannot cut metal, it loses because we repeatedly pay the coordination tax on every PDF drawing and every inbox thread. Structured ambiguity is a way to make that tax legible, then compress it with machines, without pretending the machines are infallible. The failure mode to watch is ambiguity latency, where missing intent sits in email for days and only surfaces after a toolpath, fixture plan, or 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, not just the 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 are frozen 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?
2. 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?
3. 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?
4. 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?
5. 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?