How can I reliably validate structured JSON extracted by AI from 100+ page industrial catalogs?

How can I reliably validate structured JSON extracted by AI from 100+ page industrial catalogs?

I am a mechanical design engineer working with factory automation equipment in Japan.

I regularly use technical catalogs from manufacturers such as IAI, SMC, THK, Mitsubishi Electric, and others. These catalogs can easily contain hundreds of pages, with specifications distributed across tables, model-code explanations, footnotes, diagrams, and compatibility charts.

I am currently experimenting with using AI to extract the information I need from these catalogs into structured JSON so that it can later be searched and reused for engineering tasks such as component selection and compatibility checking.

The main problem is reliability.

A typical workflow today looks like this:

  1. One AI/agent reads the catalog and generates structured JSON.

  2. A second agent reviews the extracted result.

  3. Sometimes I also ask another model, such as Claude, Grok, or DeepSeek, to independently check the result.

This helps, but I do not think it solves the fundamental problem.

Two models can agree and still be wrong.

For example, they may both:

  • read the wrong row or column in a table;

  • miss a footnote;

  • confuse specifications between very similar model numbers;

  • overlook an operating condition;

  • interpret a diagram incorrectly;

  • or repeat the same plausible but unsupported assumption.

For engineering use, β€œseveral models agree” is therefore not enough.

What I would like to build is a verification process where every extracted value can be traced back to authoritative evidence in the original catalog.

Ideally, a JSON field would contain not only the value:

{
  "max_speed": 500
}

but something closer to:

{
  "max_speed": {
    "value": 500,
    "unit": "mm/s",
    "source_page": 183,
    "source_section": "Speed / Acceleration Specifications",
    "source_text": "...",
    "verification_status": "verified"
  }
}

I am considering an architecture where:

  • one agent performs extraction;

  • another verifier independently searches the original PDF for evidence for each field;

  • deterministic checks validate things such as units, ranges, model-code relationships and compatibility rules;

  • fields without direct evidence are flagged rather than accepted;

  • and a manually verified sample is used as a gold dataset to measure the real error rate.

My main questions are:

1. What is the best way to store field-level provenance for data extracted from large technical PDFs?

2. How would you design an independent verification agent so that it does not simply inherit the first agent’s mistakes?

3. What evaluation metrics would you use to quantify the reliability of the resulting engineering dataset?

4. Is model consensus useful here, or is it better to treat models only as evidence-finding tools and rely on deterministic verification wherever possible?

5. Has anyone built a similar pipeline for technical catalogs, standards, manuals, medical documents, legal documents, or other sources where a plausible extraction is not good enough?

My eventual goal is not just to make an AI that can β€œread a catalog.”

I want to build a system where an engineer can ask something like:

β€œAre this servo motor, amplifier, power cable and encoder cable compatible?”

and receive not only an answer, but also the exact manufacturer evidence behind that answer and a clear warning whenever the system cannot verify something with sufficient confidence.

I would be very interested in hearing how people working on evals, retrieval, document extraction, or tool-using agents would approach this problem.

Can you approach the manufacturer and get API access to the databases backing the catalogues? This would save you a lot of trouble. You might have to pay, but that’s ok, it will be worth it in the end not having to maintain a monster of an extraction tool.

These catalogues do not start life as someone typing into a pdf document :slight_smile:

That is a very good point, and I am also interested in avoiding PDF extraction entirely whenever a more authoritative structured source exists.

Have you actually obtained this kind of product database, API, or structured product feed from industrial manufacturers in practice, or are you suggesting this mainly as an architectural approach?

More specifically, do you know whether manufacturers such as SMC, THK, IAI, or Mitsubishi Electric provide any partner/dealer APIs, engineering databases, product feeds, CSV/XML/JSON exports, or other structured access to the data behind their catalogs?

If such access exists, even if it requires a paid agreement or partner relationship, I would definitely prefer using that as the primary source and keeping the PDF mainly as human-readable evidence.

For manufacturers where no structured access is available, I would still need the extraction and verification pipeline, but reducing the number of catalogs that require full PDF extraction would already be a major improvement.

No but I use APIs provided by affiliate marketers to advertise products on my own websites. These are big catalogues of products, so the concept is identical.

Build a solution good enough for the manufacturers that do provide this access and the others will be scrambling to build an API and begging you to integrate theirs :wink:

I think you could start to leverage AI here to do some research for you, for example, I put your query into Codex CLI (selfishly, I was testing a new feature for my Codexometer):slight_smile:

Yesβ€”but access varies sharply. The clearest catalog-feed offering is SMC; THK supports private B2B/EDI integration;
  IAI mainly provides engineering files; Mitsubishi Electric has useful structured exports and third-party API access,
  but not an obvious manufacturer-run catalog API.

   Manufacturer              Confirmed structured access                    Practical availability
  ━━━━━━━━━━━━━━━━━━━━━━━━  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
   SMC                       EDI; static customer catalogs in BMEcat,       Commercial/customer onboarding through the
                             Excel and CSV; OCI/cXML punchout; online       regional SMC e-procurement team. This is
                             price, lead-time and order-status queries.     the strongest β€œyes.”
                             Also CADENAS/PARTcommunity CAD and EPLAN
                             product data.
  ────────────────────────  ─────────────────────────────────────────────  ─────────────────────────────────────────────
   THK                       Omni THK connects purchasing and core          Private/account-specific. I found no public
                             systems through EDI/ODO; distributor           REST API or catalog-wide CSV/XML feed.
                             ordering, quotations, delivery data and
                             past orders. Parametric product data and
                             CAD are available through PARTcommunity.
  ────────────────────────  ─────────────────────────────────────────────  ─────────────────────────────────────────────
   IAI                       Parametric PARTcommunity catalog,              Primarily per-product engineering access.
                             configurable CAD in STEP/IGES/DXF/native       No documented catalog-feed, dealer API or
                             formats, PDF datasheets, and selection         bulk CSV/XML/JSON export found.
                             tools producing quotations, drawings and
                             specifications.
  ────────────────────────  ─────────────────────────────────────────────  ─────────────────────────────────────────────
   Mitsubishi Electric FA    Selection tool exports Excel BOMs and          Good engineering-data access, but no public
                             AutomationML; EPLAN supplies an                Mitsubishi-operated, catalog-wide product/
                             authenticated REST API and commercial-data     pricing API found.
                             CSV downloads for Mitsubishi parts;
                             official CAD/document bulk-download
                             facilities.

  Some useful specifics:

  - SMC explicitly advertises static catalogs in BMEcat, Excel and CSV, EDI transaction exchange, and OCI/cXML punchout
    integration. This appears on its European e-procurement offering, so availability may depend on country and account
    size. SMC e-procurement (https://www.smc.eu/de-de/loesungen/global-services/e-procurement)

  - SMC also contributes a substantial product dataset to EPLAN. The portal currently shows roughly 45,000 SMC records,
    containing part numbers, descriptions, classifications and engineering attributes. SMC in EPLAN Data Portal
    (https://dataportal.eplan.com/parts/list?manufacturer=SMC&page=1)

  - THK’s own reporting describes Omni THK linking customer purchasing systems and distributors through EDI using its
    Omni THK Direct Order System. Access can depend on the customer’s commercial relationship, department approval and
    even a fixed corporate IP address. THK Integrated Report
    (https://www.thk.com/sg/en/products/catalog/pub/Integrated_Report_2024_en.pdf), Omni THK access details
    (https://www.thk.com/opm/jp/en/online_service/explanation/member/)

  - THK and IAI both maintain genuinely parametric CAD databases on CADENAS/PARTcommunity. These contain model-number
    construction rules and configuration parametersβ€”not merely PDFsβ€”but bulk reuse or redistribution would need
    permission from the manufacturer/CADENAS. THK PARTcommunity (https://thk.partcommunity.com/), IAI PARTcommunity
    (https://iai.partcommunity.com/3d-cad-models/?languageIso=en)

  - IAI’s selection system claims coverage of over one million configurations and can produce a quotation, drawing and
    specification after selection. Its official parametric service supports STEP, SAT, IGES, SolidWorks, CATIA,
    Inventor, DXF and other formats. IAI selection tools
    (https://www.iai-robot.co.jp/company/advantage/sentei/index.html), IAI parametric CAD
    (https://www.iai-robot.co.jp/download/cad/3d/)

  - Mitsubishi’s FA Integrated Selection Tool exports selected model numbers, quantities, prices and totals to Excel,
    and selected configurations to AutomationML. Mitsubishi FA selection tool
    (https://www.mitsubishielectric.com/fa/products/select/), export documentation
    (https://www.mitsubishielectric.com/fa/jp_en/products/selectiontool/common/help/en/CM001.html)

  - EPLAN currently lists roughly 9,800 Mitsubishi Electric records. Its documented API supports part search/details,
    manufacturers, classifications, CSV commercial-data downloads and DXF files using bearer-token authentication.
    Mitsubishi in EPLAN (https://dataportal.eplan.com/parts/list?fuzziness=0&manufacturer=MIT&page=1), EPLAN Data Portal
    API (https://dataportal.eplan.com/api/doc)

  My overall assessment:

  - SMC: likely willing and technically ready to supply a proper product feed.
  - THK: likely able to integrate orders and customer-specific data, but you would need commercial onboarding and must
    ask specifically about product-master exports.

  - Mitsubishi Electric: EPLAN is the most immediately usable API route for engineering attributes; obtain pricing,
    availability and full lifecycle coverage separately.

  - IAI: assume CAD/configurator access only unless its regional sales or distributor organization offers a private
    feed.

  For an approach to these companies, I would request a β€œproduct-master syndication feed” explicitly and specify:
  BMEcat/ETIM/eCl@ss or CSV/JSON, full and delta files, model-number rules, lifecycle status, replacements, attributes
  with units, document/CAD links, regional availability, price-list separation, update frequency and redistribution
  rights. Avoid relying on undocumented JSON endpoints behind their public sites; those are usually unstable and their
  terms rarely permit catalog replication.

So your system might start to resemble an octopus to begin with, with bespoke feed systems from each provider acting as a translation layer into your combined datastore.

But this approach will reduce error rates and leverage as much clean data as possible.

Thanks β€” this was genuinely very helpful.

Your point about going upstream to the structured product data rather than treating the PDF as the primary source has changed the way I am thinking about the whole problem.

I originally approached this mainly as an extraction-and-verification problem. Now I can see that a better architecture may be to use authoritative structured feeds wherever they exist, then fall back to PDF extraction only for the gaps.

The research you shared on SMC, THK, IAI and Mitsubishi Electric is especially useful because it gives me concrete directions to investigate rather than just a theoretical idea.

I also like your β€œoctopus” analogy β€” different supplier feeds translated into one common engineering data layer makes a lot of sense.

Thank you for taking the time to look into this. You have probably saved me from building at least part of the monster I was preparing to build. :grinning_face_with_smiling_eyes:

Pleasure! Good luck with the project!