Markdown edition

# A staged AI pipeline extracts hardware specifications from datasheets

> A two-author preprint reports that staged AI extraction produced more source-supported hardware specifications than a one-shot baseline across 20 datasheets. Figures and real design decisions remain untested.

By BIG CHANGE Editorial

Published: 2026-10-12T10:04:09.292Z
Updated: 2026-10-12T10:04:09.292Z
Canonical: https://bigchange.ai/blog/ai-hardware-datasheet-knowledge-graph-extraction

![Conceptual charcoal illustration of an unbranded electronic sensor module beside a datasheet table with one orange-highlighted row.](https://bigchange.ai/api/media/file/hardware-datasheet-sensor-spec-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE. It does not depict a studied component, a real datasheet, or a tested engineering decision.

A [University of Michigan preprint](https://arxiv.org/html/2610.12762v1) describes a way to turn hardware datasheets into searchable knowledge graphs while retaining a link from each extracted specification to its source. Across 20 datasheets, the authors report that 98.8% of the properties in their graphs were supported by their cited source passages, compared with 76.1% for a one-shot approach. The result concerns extraction quality in the authors' evaluation. It does not show that a component selected from either graph will work in a finished design.

## The big change

- **What changed:** The researchers split datasheet processing into bounded extraction, graph placement and repeated cleanup, instead of asking a model to produce the entire graph in one response.
- **Why it matters:** An engineer looking up a component constraint needs the value, its operating conditions and a route back to the datasheet. The staged approach kept substantially more source-supported properties in this comparison.
- **What to watch:** The reported scores come from 20 documents and a comparison against one one-shot baseline. Independent reproduction and tests in a real component-selection or verification workflow remain open.

## The pipeline keeps each specification tied to a source

Datasheets scatter specifications across prose and tables. A voltage range may depend on a device variant or operating mode, so an isolated number is an incomplete answer to an engineer's question. The authors' method first converts PDF datasheets to Markdown, preserves table structure and divides the text into chunks. It keeps each table intact so headings and units stay with the cells they describe. Figures are excluded from the input, a significant limit for documents that put specifications in diagrams.

The model extracts a name, description, value or range, and unit for each property it finds in a chunk. The description carries conditions, configurations and device variants where the source supplies them. Each property retains its source chunk. A second stage places the properties under functional blocks in a graph. A UART baud-rate specification, for example, belongs under a UART block; a specification shared by multiple peripherals belongs higher in the hierarchy. The model can propose a new block when the starting category template lacks one.

The system asks the model for explicit placement and editing instructions. Local software checks those instructions and applies them to stored properties, instead of having the model regenerate the graph and its values. Later passes merge duplicate specifications, distinguish properties with the same name and revisit properties placed before a more suitable block existed. This separation makes an incorrect value or placement easier to trace to a source chunk and a processing step. It does not make the model's semantic decisions infallible.

For retrieval, a system can identify relevant functional blocks and inspect their properties along with applicable properties inherited from parent blocks. That is a documented design for narrowing the search over a graph. The paper does not report a field trial showing faster engineering work or fewer compatibility failures.

## What the comparison measured

The authors ran both methods with GPT-5.4 at temperature 0.2 on 20 datasheets: seven sensors, five processing components, five power modules and three communication components. The documents total 1,040 pages. The one-shot baseline received the same parsed Markdown as the staged system and had to extract, deduplicate and organize a complete graph in one query. Both methods therefore lacked figure content in this comparison.

The 98.8% and 76.1% figures measure *property faithfulness*: whether the passage attached to an extracted property supports it. An LLM judged semantic support, while the baseline's claimed reference also had to match the input text. The researchers then compared how much of each graph's faithful information could be recovered from the other. Their staged graphs fully covered 83.6% of the baseline's faithful normalized properties. In the reverse direction, the baseline fully covered 10.5% of the staged graphs' properties.

These are directional, relative coverage scores, not a percentage of all specifications in the original datasheets. No exhaustive ground-truth inventory was available. The authors normalized properties to reduce differences in how each graph divided up a specification, then had a model judge full, partial or absent coverage. Their manual check found that 186 of 200 sampled normalization instructions followed the stated rules; eight did not and six were ambiguous. Those errors can affect the coverage totals.

The work also has a processing cost. The paper says one refinement iteration for an Analog Devices sensor graph with more than 800 properties took about 17 minutes because of model queries and API latency. Its authors chose three iterations as a tradeoff. The paper does not give a general cost per datasheet or demonstrate that the pipeline is economical at production scale.

## The engineering use remains to be tested

The experiment measured extracted knowledge, not component decisions. In the authors' test, breaking a dense document into traceable extraction and graph-editing steps produced more source-supported information than their one-shot baseline. An engineer could use a graph like this to locate candidate constraints and inspect the attached original passage. Before a component decision, the original datasheet and the applicable conditions still need human checking, especially where a figure contains information the pipeline did not ingest.

This is a two-author preprint, version 1, submitted October 8, 2026. BIG CHANGE reviewed the paper and its reported method and results; it did not run the pipeline or independently check its graphs against the 20 datasheets. The paper does not establish performance against other extraction systems, across a wider document set, or in a deployed hardware workflow.

### Sources & further reading

- [Qiao and Dick, *Faithful and Complete LLM-Assisted Automated Construction of Hierarchical Hardware Knowledge Graphs*](https://arxiv.org/html/2610.12762v1), arXiv version 1, submitted October 8, 2026. Primary source for the pipeline, 20-datasheet evaluation, scores and stated limitations. These are the authors' results, without independent replication identified for this article.

## Sources

- [Faithful and Complete LLM-Assisted Automated Construction of Hierarchical Hardware Knowledge Graphs, arXiv v1](https://arxiv.org/html/2610.12762v1) — Primary authors' paper for system method, 20-datasheet benchmark and limitations; no independent replication.
- [arXiv version record for 2610.12762](https://arxiv.org/abs/2610.12762) — Primary metadata confirming authors, v1 submission and research classification; not an independent experimental source.