Datasheet Havoc: Why Engineering Data Extraction Is Still Manual — and What AI Changes

Across process plants and capital projects, a huge amount of engineering information lives inside data-sheets.

Design pressure. Operating temperature. Materials of construction. Pump duty. Motor rating. Instrument ranges. Valve specifications. Equipment tags. Vendor model numbers.

And very often, somebody has to read the datasheet and manually transfer the information into:

Equipment registers
Instrument indexes
Valve lists
Handover databases
CMMS or EAM systems
HAZOP packages
Engineering reviews

A single datasheet may only take a few minutes to review.

But across hundreds or thousands of equipment items, instruments and vendor documents, that becomes a substantial engineering workload, in addition to misses due to human error and fatigue.

Why Isn't the Information Already Structured?

In theory, it often starts that way. An owner or EPC issues a standard datasheet template or information requirement, and the vendor fills it in.

The problem is what happens next.

As the document moves through the supply chain:

Vendors may use their own version of the template
Multiple vendor-issued revisions are created over time
Documents are converted to PDF, and sometimes scanned
Rows, fields, or sections are added, removed, or rearranged
Units and terminology vary between suppliers
The same information may appear in more than one place

By the time the datasheet comes back, the engineering meaning is usually still there, but the original structure may no longer be consistent enough for software to reliably read it field-by-field.

Datasheet Variations and Structure Challenges

This is one reason the process industry has invested heavily in standardising information exchange. CFIHOS, for example, was created to improve handover between operators, contractors, equipment manufacturers, and suppliers, covering both engineering data and documents so information can be found, exchanged, and reused more consistently across the facility lifecycle. [1][2]

Industry Has Been Trying to Solve This for Years

The desired end state is clear:

A supplier receives defined information requirements.
The supplier returns structured information against those requirements.
That information moves cleanly into the owner's engineering, maintenance and asset-information systems.

Standards such as CFIHOS help define the common language needed for that exchange, including equipment classes, properties, units and relationships. [3]

That is important progress.

But real projects still contain a mixture of structured data, spreadsheets, PDFs, scans and historical files from many different suppliers and systems.

So even when the destination is structured, somebody still has to bridge the gap between the document and the database.

Traditional Automation Helped — But Mainly Where Documents Were Predictable

Earlier document-extraction systems generally relied on templates, fixed positions, text recognition and rules.

If every vendor returned exactly the same datasheet layout, this could work very well.

For example:

“Design Pressure is always in this box on page 2.”

The difficulty starts when the next vendor moves the field, changes the table, uses a different unit, adds a page or sends a scan.

Then the extraction logic needs to adapt again.

This made automation useful for tightly controlled document sets, but much harder across the variety of documents found on real industrial projects.

The persistence of the problem is visible even in current engineering-information platforms.

Hexagon, for example, describes using AI in HxGN SDx2 to automate tag extraction from varied engineering sources and match those tags against existing databases, specifically to reduce manual work and errors. [4]

The Problem Is Bigger Than Simply Reading Text

Suppose a system successfully reads:

Design Pressure: 15 barg

That is useful. But engineering data extraction has another layer. What if another vendor writes:

15 bar(g) or 1.5 MPa(g)

The system needs to understand that these represent equivalent engineering information.

That is partly a normalisation problem — exactly the kind of issue standards such as CFIHOS address through common classes, properties and units [3]. In practice, CFIHOS adoption is inconsistent, and it offers little help with the vast installed base of existing operating assets whose documentation predates the standard entirely and was never going to be retrofitted into it.

But then there is an even harder problem.

What if the latest P&ID shows a different equipment tag than the datasheet? What if revision C changed a value but the equipment register still shows revision B? What if two pages of the same vendor package disagree with each other?

For a solution to be useful in building a tag list, preparing a HAZOP, troubleshooting a live plant, or working through an MOC, the requirement is no longer simply:

“Can software read this PDF?”

It becomes:

“Can software understand the engineering information well enough to know what it means and where it came from?”

This Is Where Modern AI Becomes Interesting

Modern multimodal AI can interpret documents much more flexibly than traditional fixed-template extraction.

Instead of relying entirely on a field appearing at a predefined coordinate, the system can use the surrounding text, table structure, document, and project context to determine what a value represents.

That makes it possible to work across changing layouts and terminology without creating a new extraction rule for every document format.

But replacing OCR with an AI model does not automatically make the information trustworthy.

For engineering use, a useful system should be able to answer:

What did you extract?
Where exactly did you find it?
How did you interpret the unit or terminology?
Does anything elsewhere in the project appear to contradict it?
What could you not determine confidently enough to populate automatically?

That changes the workflow.

Instead of an engineer manually reading every field of every datasheet, AI can perform the first pass.

The engineer reviews the values that need judgment: low-confidence fields, conflicts, missing information, and unusual cases.

The objective is not to remove engineering review.

It is to make that review far more focused.

The Bigger Opportunity Is Source Traceability and Reuse

There is another important implication.

Once a datasheet has been understood and validated, why should that engineering information be extracted again for the next task?

The same equipment data may later support:

An asset register
Vendor-document review
P&ID checks
HAZOP preparation
Modification reviews
Handover
Troubleshooting in an operating plant

Source-Traceable Engineering Extraction Workflow

The extraction itself becomes infrastructure for engineering work, done by AI reviewed by Humans.

That is where the value can extend well beyond the original document-processing task.

At Novek AI, this is the problem we are working on.

Not simply pulling text from engineering documents.

The goal is to turn those documents into engineering information that is:

Source-traceable, reviewable, correctable, and reusable.

If it extracts a design pressure, pump duty, or instrument range, the engineer should be able to point exactly where that value came from throughout the lifecycle.
If two documents disagree, the system should surface the conflict rather than silently choosing one.
If it cannot determine something reliably, it should ask for review rather than guess.
And once that information has been verified, the same understanding can be reused across the workflows that depend on it.

The opportunity is not simply to make document reading more automated.

For many engineering teams, the more immediate opportunity is much simpler:

Stop making engineers repeatedly read and re-type information that already exists inside their documents.

Then make that extracted information trustworthy and traceable enough to reuse.

References

CFIHOS — About — CFIHOS describes its purpose as providing practical, standardised information-handover specifications for industrial facilities across operators, contractors, equipment manufacturers and suppliers. It explicitly organises both data and documents in a structured way.
IOGP — CFIHOS Explained — IOGP explains that CFIHOS is intended to make information handover quicker, easier and safer across operators, contractors, equipment manufacturers and suppliers.
CFIHOS — Reference Data Library Development Guide — The CFIHOS RDL provides the common reference structure used to standardise engineering information across the supply chain, including equipment-related data definitions.
Hexagon — The Role of Artificial Intelligence in HxGN SDx2 — Hexagon describes using AI to extract tags from varied engineering sources and match them against existing databases, reducing manual work and errors.