Product Data Enrichment for Industrial Catalogues: AI Fills Gaps

Coding Liquids tutorial cover featuring Sagnik Bhattacharya for Product Data Enrichment for Industrial Catalogues: AI Fills Gaps.
Coding Liquids tutorial cover featuring Sagnik Bhattacharya for Product Data Enrichment for Industrial Catalogues: AI Fills Gaps.

Define the attributes your buyers actually filter on, extract each value from the manufacturer's datasheet with the page and quoted text it came from, return blank rather than guess, flag a confidence level, and have a person audit a sample weighted towards the risky attributes. Only then load the values into the catalogue.

This differs from enriching a shopping feed. A consumer product needs a colour and a good description. An industrial item such as a valve, bearing or contactor is bought on numbers: pressure rating, bore, temperature range, voltage, material, thread. A wrong number is not a weak listing; it is a wrong part ordered, a returned pallet or, worse, a part used beyond its rating. The method below is built around that difference.

Follow me on Instagram@sagnikteaches

The job in numbers: a valve and fittings distributor

A distributor holds 6,200 active items from about 30 manufacturers: ball valves, check valves, couplings and flexible hoses. Search on the website is poor because many records carry only a part number and a one-line description. An audit of the catalogue (illustrative figures) finds that 38 per cent have no pressure rating, 52 per cent no operating temperature range, 27 per cent no body material and 61 per cent no seal material. Counter staff answer the same spec questions by phone because the site cannot.

Connect on LinkedInSagnik Bhattacharya

The goal is not to fill every cell. It is to fill the six or seven attributes that buyers filter on, accurately, for the parts that sell, and leave an honest blank elsewhere. For this distributor the first run covers the top 1,800 items by revenue, which account for most orders, using the datasheets already on file.

Subscribe on YouTube@sagnikteaches

Step 1: write the attribute schema before touching a datasheet

A schema is a short list of fields with a name, a type, a unit and rules. Without one, the model returns whatever the datasheet calls things, and "max working pressure", "PN" and "rated pressure" become three columns. Build it as a table, one row per attribute, per product family, because a valve and a hose do not share attributes.

AttributeTypeCanonical unitAllowed values or ruleSafety-critical
Body materialchoicenoneBrass, Stainless 304, Stainless 316, Carbon steel, PVC, OtherYes for drinking water
Connection sizetextinch or mm, as printedKeep the supplier's size designation exactlyNo
Maximum working pressurenumberbarOnly a stated working pressure; not test pressureYes
Temperature rangetwo numbersdegrees CelsiusMinimum and maximum, as statedYes
Seal materialchoicenonePTFE, EPDM, NBR, FKM, OtherYes for chemicals
Connection typechoicenoneFemale thread, Male thread, Flanged, CompressionNo
ApprovalslistnoneOnly approvals named in the document, with the standard's printed nameYes

Notice the "rule" column. Working pressure and test pressure are different things on datasheets, and a model will quietly use whichever it sees first unless told. Notice too the safety flag, which drives how much human checking each attribute gets later. Where your trade already uses a classification standard (some industries use ETIM or ECLASS for attribute definitions), check whether your customers or marketplaces expect those names before inventing your own.

The Complete Excel Course with AI Integration thumbnail

The Complete Excel Course with AI Integration

From formulas and pivot tables to Power Query, DAX, VBA and AI with Copilot, ChatGPT and Claude — hands-on from the first lesson.

By Sagnik Bhattacharya and Virginia Thorn, Primetime Emmy Award winner

Buy now

Step 2: get the source documents in order

The extraction can only be as good as the document. Match every datasheet to a part number, and note whether the sheet covers one product or a family. A family datasheet with a table of twelve variants is the common case, and the model must pick the right row. Store the file name and revision date beside each record, so you can say which version of the manufacturer's sheet a value came from.

Split long catalogues. Claude, for example, accepts PDFs up to 1,000 pages, but it reads the visual layout only up to 100 pages, so tables in a 400-page catalogue may be read as plain text and come out jumbled. Cut a big catalogue into chapters of 30 to 60 pages for extraction. If a datasheet is a scan of a paper page, run it through text recognition first and treat its results as lower confidence.

Step 3: the extraction prompt that returns evidence

The prompt has four jobs: restate the schema, forbid guessing, demand evidence and make the output machine-readable. Evidence is the single most useful requirement. If the model must quote the exact words and the page, a checker can verify the value in ten seconds without searching the PDF.

You will receive one manufacturer datasheet and a part number.
Extract the attributes in the schema below FOR THAT PART NUMBER ONLY.
If the sheet is a family table, use the row for this part number; if you cannot find the
part number, return NOT FOUND for every field.

Rules:
- Use only what the document states. Never infer from the product name or from similar parts.
- If an attribute is not stated, return null.
- Pressure: working pressure only, not test or burst pressure. Return the number in the unit
  printed; I will convert units myself.
- For every value give: value, unit as printed, page number, and the exact words quoted.
- Confidence: HIGH if stated in plain text next to the part number; MEDIUM if read from a
  table or inferred from a column heading; LOW if the table was unclear or the page was scanned.

SCHEMA: [paste the table above]

Return JSON: one object per attribute with value, unit, page, quote, confidence.

An illustrative reply for a brass ball valve:

{"body_material": {"value": "Brass", "unit": null, "page": 1, "quote": "Body: forged brass CW617N", "confidence": "HIGH"},
 "max_working_pressure": {"value": 25, "unit": "bar", "page": 2, "quote": "PN25 (cold non-shock)", "confidence": "MEDIUM"},
 "temperature_range": {"value": [-20, 120], "unit": "C", "page": 2, "quote": "-20 to +120", "confidence": "MEDIUM"},
 "seal_material": {"value": null, "unit": null, "page": null, "quote": null, "confidence": null}}

Check what you would fix. The model has treated "PN25" as a working pressure of 25 bar, which is a judgement rather than a quote of a pressure figure, and the pressure and temperature relationship on such sheets is often given as a curve rather than one number. That is why it is MEDIUM, and why working pressure is on the safety list: a person reads the original wording and decides whether "25 bar" is how your catalogue should state it. The seal material is correctly null; the sheet does not say.

Step 4: validate in code and formulas before anyone reads it

Several errors can be caught without a human. Run these checks across the whole output.

  • Quote must exist in the source. Search the extracted text of the datasheet for the quote string. A quote that is not in the document means the model paraphrased or invented it; reject the value. This single check catches most fabrication.
  • Choice values must be in the list. Anything not matching the allowed values goes to review, and "Other" is a prompt to extend the list, not to hide the problem.
  • Range sanity. A minimum temperature higher than the maximum, a pressure of 2,500 bar on a PVC valve, or a bore larger than the nominal size are signals of a column misread.
  • Unit conversion by formula. Convert psi to bar with a fixed factor of about 0.0689, and Fahrenheit to Celsius with the standard formula, in a spreadsheet column. Keep the original beside the converted value.
  • Family consistency. Parts in one family usually share a body material. If one row differs, check it.

Step 5: the audit sample, weighted by risk

After the automatic checks, a person reads a sample. Do not sample evenly: weight it by the cost of being wrong. A reasonable rule for the valve run of 1,800 items:

GroupReview rateWhy
Safety-critical attributes (pressure, temperature, approvals)Every LOW and MEDIUM; 15% of HIGHWrong values can cause harm or returns
Choice attributes from tables10% of MEDIUMRow misreads cluster here
Plain text attributes at HIGH3% to 5%Low risk, high volume
Anything validated as out of rangeAllKnown suspects

Record each reviewed value as correct, wrong or unsupported (the document does not say what the model said). Calculate the error rate per attribute, not overall. An illustrative result: body material 1 wrong in 90 (about 1 per cent), seal material 4 wrong in 80 (5 per cent), pressure 9 wrong in 100 (9 per cent). The pressure error rate is too high to publish, so the answer is not to accept it but to find the pattern. Perhaps six of the nine come from one manufacturer whose datasheets show test pressure in bold at the top. Fix the instruction for that manufacturer, rerun just those parts, and audit again.

Set a publish threshold before you start. For example: safety-critical attributes publish only at under 1 per cent errors in a clean 100-item sample; others at under 3 per cent. Writing it down stops the temptation to lower the bar when the deadline gets close.

Step 6: publish with provenance, and keep the blanks

Load the validated values into your product information system or catalogue sheet along with the source file and page. If your website can show it, a line such as "Data from manufacturer datasheet, revision B" tells a buyer where the number came from. Keep the null values honest: a "see datasheet" link is better than a guess, and a buyer's filter that excludes unknowns is better than one that includes wrong ones.

Plan the second round from the blanks. The attributes still missing show which manufacturers send poor data; a short email to them asking for a current datasheet costs less than guessing. Use the answers to guide your supplier management too, since a manufacturer that publishes clear data is easier to sell for.

Four sector examples of the same method

Electrical contactors

Attributes like coil voltage, number of poles and rated current appear in dense tables with several variants per row. Make the part number the key, ask for the column heading that each value was under, and treat any cell where the heading is more than one line as MEDIUM. Rated current has several values (by category of use), so the schema must say which one the shop lists.

Bearings and fasteners

Many numbers here follow a standard designation, so a model can often check a value against the part number itself. Add a rule that extracted bore, outer diameter and width must agree with the part number's designation where the shop's convention allows it, and send disagreements to review.

Chemical-resistant hoses

The attribute that matters is compatibility, which datasheets give as a table of chemicals against ratings. Do not summarise it. Store the table as a document link, and extract only the headline attributes the shop is willing to stand behind. A summary of a chemical compatibility chart by a model is the kind of thing you should not publish.

Care-home and childcare furniture suppliers

Not all industrial catalogues are about pressure. A supplier of beds and seating to care agencies and nurseries needs safe working load, fire-retardancy marking and cleaning instructions. The same method applies, with load and fire rating on the safety list.

A mistake that surfaced in the sample

An illustrative case worth rehearsing: the first run reports a maximum temperature of 80 degrees for a hose, but the datasheet says "continuous 80 C, intermittent 100 C". The model returned 100 because the second figure was larger and the instruction said "maximum". The quote check passed, since both figures are in the text. A human reviewer saw it because temperature was on the safety list and the value was MEDIUM. The fix was a schema change: two attributes, continuous and intermittent maximum temperature, and a rule never to merge them. The lesson is that evidence checks prove a value exists in the document, not that it means what the attribute says.

The 1,800-item run, start to finish

Here is how the numbers might fall for the distributor, all illustrative. The 1,800 items map to 410 datasheets, because most sheets cover a family. Extraction runs per datasheet, with every part number in that family listed in the prompt, so there are 410 calls rather than 1,800. The output holds roughly 12,600 attribute values (seven per item).

  • Automatic checks reject 640 values: 410 where the quote is not found in the document, 120 outside the allowed list and 110 failing range sanity. Rerunning those with the error stated gets 470 of them through, leaving 170 for hand work.
  • About 9,100 values come back HIGH, 2,800 MEDIUM and 700 LOW or null.
  • The audit reads all LOW and MEDIUM safety-critical values (around 900), 15 per cent of HIGH safety values (about 230) and a few per cent of the rest, roughly 1,500 values in all. At 20 seconds a value with the quote on screen, that is about eight hours of reviewing, or two half-days for one person.
  • After corrections, 11,730 values publish, 700 stay blank because the datasheet is silent, and the 170 that failed twice are queued for a manufacturer enquiry.

The time is mostly in review, which is the right place for it. Compare that with typing 12,600 values by hand: at 40 seconds each, finding the sheet, the page and the cell, that is 140 hours.

Datasheets that disagree with your records

Many items already have some data, entered years ago by someone who has since left. When extraction disagrees with the existing value, do not overwrite automatically. Produce a conflicts list with the old value, the new value, and the quote, and have a person decide. Often the datasheet is newer; sometimes the old record reflects a variant the sheet does not cover. Either way, a conflict is information about your data's reliability.

Compare the EXISTING value with what this datasheet states, for each attribute below.
Return only attributes where they differ, as: part number | attribute | existing | datasheet | quote | page.
Do not decide which is right.

Reading a family table: a filled-in example

Family tables are where most errors start, so rehearse one. Suppose a datasheet lists four ball valves in rows, with columns for part number, size, pressure and weight, and the same sheet carries a footnote under the table: "Pressure for sizes above 2 inch is reduced by 20 per cent above 60 C." The distributor sells the 2.5 inch variant.

Part      Size     Pressure   Weight
BV-100    1 inch   40 bar     0.45 kg
BV-150    1.5 inch 40 bar     0.90 kg
BV-200    2 inch   25 bar     1.40 kg
BV-250    2.5 inch 25 bar     2.10 kg

A correct extraction for BV-250 returns 25 bar, page 3, confidence MEDIUM, and attaches the footnote as a condition. A weak one returns 25 bar and loses the footnote, so a buyer running hot water at 80 C is told 25 bar when the sheet implies 20. This is why the schema should carry a "conditions" field for safety-critical values, and why the prompt says "include any footnote that qualifies this value". Test the prompt on five tricky family tables like this one before running the 410.

Choosing the tool for the job

For a few hundred datasheets, a chat assistant with file upload is enough: upload a sheet, paste the prompt, copy the JSON into a sheet. Business plans of ChatGPT and Claude do not train on business content by default, and consumer plans have a switch for it, so check which plan your team uses before uploading manufacturers' material that carries confidentiality terms. Past a thousand sheets, a script that calls the model's API one sheet at a time saves hours, and that is the point to get someone to build it once. Keep in mind that API use is billed separately from a chat subscription, by usage; some higher-tier ChatGPT and Claude plans now include a monthly API credit, so check what your plan covers before budgeting the run.

Whichever route, keep the same three records for every run: the prompt version, the date and the model name, and the sample audit result. If an attribute turns out to be wrong a year from now, those records tell you which batch it came from and what to recheck.

Revisions and a refresh routine

Manufacturers revise datasheets, sometimes changing a rating or a material. Store the revision date and file name with each value, and once or twice a year re-download the sheets for your top sellers and run the conflicts prompt against the stored values. A change in a safety-critical attribute should trigger a note to whoever sells that part, and a check of stock already on the shelf. This is a small job done regularly and a large one if left for five years.

Using the enriched data

Once attributes are populated, they pay for themselves in three places: website filters, quote responses and spec answers. A sales desk that can filter 6,200 items by pressure and material answers a call in minutes. The tutorial on answering spec questions from datasheets shows how to put the same data in front of staff or customers. If your catalogue is also going to a marketplace with its own category tree, assign categories first, because attributes differ by category, and the same careful check of valid values applies.

Budget the work honestly. For 1,800 items, a day to write and test the schema and prompt, one to two days of runs and automatic checks, and one to two days of human review is a realistic shape, and the review is the part that does not shrink. If you would rather map the schema and the review step with someone who has done it before, that is a typical use of my AI implementation consultation, via the contact page.

Enrichment questions from technical suppliers

Should the AI fill a blank when the datasheet is silent?

No. The rule is: extract what the document states, return null when it does not, and never infer a rating or material from the product name. A blank is visible and fixable; a plausible guess in a pressure rating or temperature limit is a hidden fault that a buyer may rely on.

Can AI read scanned datasheets and tables?

Often, but with more errors. Claude reads PDFs up to 1,000 pages, though it uses visual layout only up to 100 pages, so very long catalogues should be split. Tables and scanned pages are where misreads cluster, so audit those more heavily than clean text pages.

Which attributes need a person to sign off regardless of confidence?

Anything a buyer could rely on for safety or compliance: pressure and temperature ratings, load capacities, electrical ratings, certifications and approvals, and materials for food or drinking-water contact. Mark these in the schema as safety-critical and route them to a named reviewer every time.

How do I handle the same attribute in different units?

Store one canonical unit per attribute, keep the original text beside it, and convert with a formula, not by asking the model to calculate. For example, keep bar as the unit for pressure and convert psi values by a fixed factor, then spot-check a few conversions by hand.

Further reads

Sources: Claude help centre on document uploads and PDF limits, and on API billing; OpenAI business data page and Anthropic commercial terms on model training; ETIM International and ECLASS websites.

Want your catalogue attributes filled in and checked?

On a 1:1 call we can look at your product data and datasheets, choose the attributes worth filling first, and design the review step so nothing risky is published unchecked.

Book a 1:1 call with me