Extracting Product Attributes from Spec Sheets, PDFs, and CAD Files

Attribute extraction looks like a solved problem because the demonstration always uses the easy document. A clean, born-digital PDF with a labeled specification table is solved, and has been for years. Very few of the documents that decide whether a product can be sold look like that.

The documents that matter are installation manuals, submittals, price books, engineering drawings, and CAD models. They were written to help a technician install a part or a machinist cut one. Nobody who produced them was thinking about a product record. The information is all there. It is simply arranged for a different reader.

What follows is how the difficulty is actually distributed across those source types, and why the harder half of the problem starts after the extraction step rather than during it.

The difficulty is a ladder, not a level

Treating extraction as one capability is the first mistake. A pipeline that reports a single accuracy number across a mixed document set is averaging five different problems, four of which it is probably not solving.

Born-digital PDFs with a text layer. This rung is genuinely solved. The characters are already there and do not need to be recognized. The only real difficulty is reading order, because a two-column layout with sidebars and footnotes has no inherent sequence, and a naive reader interleaves them. Well understood, and not where anyone should be spending effort.

Scanned and image-only PDFs. No text layer, so the characters have to be recognized rather than read. Optical character recognition is strong now on a clean scan at reasonable resolution. It degrades in the conditions that describe most industrial archives: a price book faxed twice in 2011, a stamp obscuring a model number, a page scanned at a slight skew, a table whose rule lines faded until the columns stopped being visible as columns.

Tables. Here the characters stop being the problem and structure becomes the problem. A specification table is not text. It is a grid of relationships, and the relationship is what carries the meaning. A header cell merged across three columns applies to all three. A unit declared once in a header applies to every value below it and appears nowhere near them. A footnote marker changes a value conditionally. A row continues onto the next page under a repeated header and becomes two records unless something notices. Read the structure wrong and the output is worse than nothing: values with perfect character accuracy, attached to the wrong attribute, carrying no signal that anything went wrong.

Line drawings. Two things make these hard, and the second one is the interesting one.

The first is that the text in a drawing is not laid out like text. Dimension values sit along leader lines, rotated to whatever angle annotates the feature, sometimes at ninety degrees, sometimes upside down relative to the page. Drawings are frequently dual-dimensioned, with millimeters primary and inches in brackets, or the reverse. A reader that assumes horizontal lines of text finds a fraction of what is on the page and has no way of knowing what it missed.

The second is that the values are often not in the drawing at all. A single drawing routinely represents an entire product family. The dimensions are letter callouts, A, B, C, D, keyed to a table elsewhere in the document where each row is a model number. This is a deliberate convention, used precisely so that one drawing can serve many parts without repeating dimensions or running long leader lines.

The consequence for extraction is that the geometry and the values live in two places. The drawing carries the shape and the letters. The table carries the numbers under headings named A through H. Neither is a product record. An extractor that reads the drawing returns a diagram annotated with letters. An extractor that reads the table returns a grid of numbers with meaningless column names. Only a system that understands the two are the same document produces the thing anyone wanted, which is the height of model 4B in inches.

That is a join, and the join key is a drafting convention rather than a standard. It varies by manufacturer, and sometimes by document within a manufacturer. It is also the single most common reason dimensional attributes are missing from industrial catalogs, and it is almost never described as an extraction failure, because nothing failed loudly. The pipeline read both pages and returned nothing usable from either.

CAD files. A CAD file is not a document. It is a model, and what you can pull out of it depends heavily on which kind you were sent.

Geometry is the reliable part. Bounding dimensions, volume, and mass properties where density is defined are derivable from the model itself rather than read off a page, which makes them more trustworthy than anything recovered by OCR.

Manufacturing information is where the formats diverge. Dimensions, tolerances, geometric dimensioning and tolerancing, surface finish, and notes can be carried either as semantics or as pictures of semantics. STEP AP242 was designed to carry product and manufacturing information a machine can interpret, with tolerances and datum features attached to the geometric entities they govern. Earlier protocols such as AP203 and AP214, and graphical-only annotation in any format, carry the appearance of the annotation without its meaning. Two files that look identical when opened can differ completely in how much a pipeline can read from them. Two-dimensional formats such as DWG and DXF are drafting geometry, lines and text entities with coordinates, which returns you to the line-drawing problem with better inputs and the same join.

Then there is the part no extraction technique addresses. A CAD model describes a part as manufactured. A product record describes a thing as sold. Packaged dimensions, shipping weight, carton quantity, what is actually in the box, and which finishes are orderable variants rather than configuration options are not in the model, because the model does not know it is a SKU. Recovering those is a different exercise, and pretending the model contains them produces confident, wrong records.

An extracted value is a claim, not a fact

Assume every rung above is handled. There is still a step that most pipelines skip entirely.

Ask three documents for the same attribute and you will frequently get three answers. The spec sheet gives one value, the installation manual gives another, the price book gives a third. Usually none of them is an error. All three were correct when they were written, and one or two are a revision behind. The catalog has to pick one, and picking one is a decision, not a read.

This is why provenance is not administrative overhead. Every extracted value needs to carry where it came from, which document, which page, which revision, and by what method it was recovered. Without that record there is no way to adjudicate a conflict, no way to re-run a decision when a document is superseded, and no way to answer a customer who disputes a number. A value with no provenance cannot be defended, and anything that cannot be defended should not have shipped.

Precedence then has to be a stated rule rather than an accident of processing order. Which document class wins, how revision dates break ties, and what happens when the winning source is silent are policy questions that belong in the pipeline explicitly. Systems that leave this implicit produce catalogs whose values depend on the order the files happened to arrive in, which is not a system anyone can reason about.

Accuracy scores measure the wrong thing

Extraction research reports accuracy, usually as an F1 score, and the numbers are high. Walmart’s published work on their attribute extraction framework reports an average 92.5 percent F1 on text attributes, which is strong performance on a hard problem, and the paper is worth reading.

An average is the wrong shape for this decision, for three reasons.

The first is arithmetic. Ninety-two percent across 63 attributes on 50,000 records leaves on the order of a quarter of a million incorrect values, distributed invisibly through the catalog. Nobody is inspecting a quarter of a million values by hand, so in practice the error rate is not a known quantity that can be managed. It is a rate at which surprises arrive later.

The second is that the errors are not interchangeable. A missing specification loses a sale, which is bad and recoverable. A wrong dimension is ordered, shipped, installed, and returned, and it takes the customer relationship with it. Averaging those two outcomes into one number destroys the only distinction that matters operationally.

The third is the failure mode of generative extraction specifically. When a model reading a smudged dimension gets it wrong, it does not return a blank. It returns a plausible number, in a sensible range, in the correct unit, formatted exactly like the values around it. It survives every check a reviewer performs by eye, because it was produced to look precisely like a correct answer. A blank field announces itself. A confident wrong value does not, and it is the more expensive of the two by a wide margin.

The measure that actually reflects risk is not average accuracy. It is what share of delivered values were verified against the rules of the category they belong to, and what share were shipped because nothing objected. Those are very different numbers, and only one of them is usually reported. There are better dimensions to measure product data on, and an extraction accuracy score is not among them.

What has to happen after the read

Extraction is the first stage of the pipeline, and treating it as the whole pipeline is the structural error underneath most of these failures. Getting a number off a page is a capability. Knowing whether the number is allowed to be that value in that category is a different capability, and it is the one that decides whether a record can be delivered.

That is the layer atronous is built around. AI handles the generative work of reading documents that were never structured for a catalog. Deterministic logic validates every value that comes back, against a constraint layer covering more than 400 product categories, each with its own vocabulary, unit conventions, allowable variant dimensions, and identifier rules, enforced independently. A rule that is correct for air handlers is a defect applied to fasteners, which is why the two are never allowed to share a rulebook. The generation and the validation are separate systems by design and are never conflated.

Identifiers pass through up to seven checks before delivery, covering format, check digit, GS1 cross reference, uniqueness, MPN correlation, and provenance. A typical enterprise run returns 18 distinct categories of data quality issue, each flagged with its rationale rather than dropped in silence. A 50,000 record delivery runs at a success rate of 98 percent or better, with a 100 percent identifier pass rate and no duplicate identifiers. Every rule change is logged by date, source, and reason, so a value delivered last quarter can still be explained this quarter.

The principle underneath all of it is that a validated subset with documented exceptions beats a complete file with hidden errors. Ten thousand verified records and a flagged remainder is a good outcome. Thirteen thousand records with an unknown error rate is a problem that surfaces after go-live, which is the worst possible time to find it.

On the specific document types, the schematic extraction work covers how diagrams are isolated and labeled out of cluttered technical documents. Everything recovered from those sources is classified into the right category before verified records are delivered to a PIM or ERP, where the customer’s own systems take over.

There is a reason to care about this now that did not apply five years ago. Product records are increasingly read by AI agents rather than by people, and an agent comparing two products does not look at photography or copy. It compares attributes, and it has no way to tell a verified dimension from a plausible one. Catalogs built so that every value can be traced to a source and checked against a rule are the ones those systems will be able to rely on. That is where commerce is heading, and it raises the cost of a confidently wrong number considerably.

See your own data measured

The fastest way to know how much of your product information is recoverable is to see a sample of it run. That is what the atronous Data Quality Assessment does. Send up to 50 SKUs out of your PIM or ERP, exactly as they live in your system, and we run them through the same pipeline our enterprise customers rely on. Within five business days you receive the sample back, generated and validated, along with the taxonomy and schema recommendations behind the work and a working session to walk through what we found.

No pitch. Your own records, measured against the rules of their categories.

Request your Data Quality Assessment, or see how atronous handles technical and industrial product data.

Intelligence in every attribute.