Discover why legacy engineering data holds back AI adoption in construction, and how ingestion, standardisation, knowledge graphs and data lineage create a reliable, reusable data foundation.
Construction organisations are under pressure to improve project efficiency, manage costs and make better use of increasingly complex engineering information. AI offers opportunities across design, planning, risk assessment and asset management. Yet many organisations face a fundamental obstacle before these applications can deliver value: their data is fragmented across legacy systems, inconsistent formats and disconnected project records.
The challenge is not simply that engineering knowledge sits in drawings, specifications, manuals and reports. It is that this information has not always been engineered into consistent, connected and reusable data.
The industry’s AI ambitions are moving faster than its ability to make existing information usable. Addressing that gap requires more than digitisation or document search. It requires a data engineering foundation that can transform legacy information into reliable data assets.
Construction projects generate information across every stage of the lifecycle. CAD drawings and BIM models describe design and geometry. Specifications define technical requirements. Equipment manuals and product datasheets capture component properties. Project records document decisions, revisions and delivery.
However, these sources are rarely created with seamless data integration in mind. Different contractors, engineering teams, manufacturers and software platforms may use different naming conventions, identifiers, units and data structures. Information that refers to the same component can be represented differently across a drawing, a specification and an asset record.
This creates friction in everyday work. Teams spend time locating the correct documents, reconciling inconsistent records and checking whether information reflects the latest revision. Knowledge from completed projects can be difficult to retrieve for new work, even when similar components or requirements have been encountered before.
That friction is also a commercial risk. When design, procurement and site teams work from records that do not match, the result is design clashes, procurement mismatches and confusion over which revision is current. Construction megaprojects routinely face 10-20% margin erosion from these issues, and each one threatens project delivery schedules through rework, delayed orders and stalled site activity.
The consequences extend across the construction ecosystem. Core construction teams need reliable project information. Equipment and plant businesses need to connect assets with technical records. Construction products and materials organisations need consistent product data. Architecture, engineering and professional services firms must preserve design intent and technical requirements. Construction data, analytics, risk and intelligence teams need information that can be compared and analysed. ConTech providers face the challenge of working with data originating from different tools and workflows.
These are not separate problems. They are symptoms of a wider data engineering challenge: information is captured, but not consistently integrated, standardised and modelled for reuse.
The Royal Institution of Chartered Surveyors' 2026 research on AI in construction and commercial property also highlights the gap between AI adoption and organisational readiness, with data quality and systems integration remaining important barriers. This points to a constraint that is rarely model capability. It is the lack of a standardised semantic foundation connecting engineering design to field execution.
Digitising a drawing or extracting text from a PDF can improve accessibility, but it does not automatically make the information suitable for analytics or AI.
Consider a structural component represented in a CAD file, referenced in a project specification and recorded in a spreadsheet. Each source may contain useful information, but the identifiers may not match. Units may differ, attributes may be incomplete, and the relationship between the component and its technical requirements may exist only in the knowledge of the engineer who created the records.
A search tool may retrieve all three sources without establishing that they refer to the same component. An AI application may extract a relevant value without knowing whether it belongs to the correct asset, revision or project context.
This is what we can call Unstructured Data Amnesia. When an OCR tool or standard search engine indexes a PDF drawing, it sees text strings but does not read the spatial, functional and component-to-specification relationships that give those strings meaning. The characters are retained, but the engineering context is lost. AI cannot reason about constructability or verify compliance if it cannot determine whether a specification note on sheet 4 applies to the structural column identified in CAD layer 12.
This is where data engineering becomes central. The work involves bringing information together, resolving inconsistencies, defining common representations and preserving relationships between records. It also requires maintaining links to source material so that extracted information can be checked.
Without these foundations, organisations risk building AI applications on data that is accessible but not sufficiently consistent or contextualised for the intended use.
Turning legacy engineering information into reusable data requires a connected approach to ingestion, transformation, modelling and governance.
1. Ingesting data from fragmented sources
Construction data is distributed across CAD and BIM files, PDFs, spreadsheets, specifications, product records and project systems. Data ingestion brings these sources into a process where they can be interpreted and worked with consistently.
The challenge is that each format carries different types of information. A drawing may contain geometry and layer structures, while a specification contains requirements in text. A BIM model may represent elements and their properties, while a spreadsheet uses project-specific identifiers.
A robust ingestion approach must account for these differences rather than treating every source as plain text. This creates a foundation for combining information without discarding the technical details that make it meaningful.
2. Standardising and validating engineering data
Once information has been extracted, it must be reconciled. Different contractors may label the same component in different ways, while identical labels may refer to different things depending on the project or discipline. Units, identifiers, attributes and terminology need to be handled consistently.
Industry standards provide the common reference point. Uniclass 2015 classifies elements, systems and products across UK projects, while OmniClass and MasterFormat serve a similar purpose in North America, with MasterFormat focused on specification sections. ISO 19650 sets out how information should be identified, structured and managed across the asset lifecycle, including consistent metadata. Mapping disparate contractor naming conventions to these frameworks gives each component a shared, governed identity. A column labelled one way in a drawing, another in a specification and a third in an asset register can then resolve to the same classification and metadata, rather than remaining three unrelated records.
Data normalisation and validation help keep that mapping reliable. They make it easier to identify duplicate or conflicting records, flag missing classification or metadata, and assess whether information is complete enough for its intended use.
This is particularly important for construction products and materials, equipment records and cross-project analytics, where comparisons depend on the underlying data being interpreted consistently. It also matters for enterprise engineering clients, who need information to meet their own data governance requirements.
Standardisation should not erase meaningful differences between projects. The objective is to establish common structures while retaining the distinctions required by engineering context, so original project terminology and source references are kept alongside the standard classification.
3. Modelling relationships, not just storing records
A database of extracted values can still leave engineering knowledge fragmented if the relationships between those values are not represented.
Data modelling provides a way to connect components, specifications, materials, drawings and associated records. Knowledge graphs offer one approach, representing engineering entities and the relationships between them so that information can be queried across sources.
For example, a component in a drawing could be linked to its relevant technical specification and supporting documentation. The resulting structure makes it easier to trace the information associated with that component rather than retrieving each record independently.
Merit Data & Technology explores this approach in its published work on engineering intelligence with KIAA, describing how CAD, BIM and document information can be parsed, normalised and assembled into queryable knowledge graphs.
The data engineering value lies in transforming disconnected records into a coherent representation of engineering information, with relationships that can be used by downstream analytics and AI applications.
4. Maintaining lineage, revisions and data quality
Engineering information changes throughout a project. Drawings are revised, specifications are updated and decisions may supersede earlier requirements. A data pipeline that captures information without preserving its source and revision context can introduce uncertainty rather than resolve it.
Lineage and traceability help establish where information originated and how it relates to its source. Validation processes can then support checks on extracted data and its relationships, while revision handling helps teams assess whether a record remains appropriate for a particular task.
These controls matter when information informs technical decisions. AI-generated outputs should not be treated as reliable simply because they are produced from structured data. The quality, context and provenance of that data still need to be assessed.
The purpose of data engineering is not to create another repository. It is to make information more usable across the activities that depend on it.
For core construction and architecture and engineering services, connected data can help teams locate relevant design information and technical requirements without repeatedly reconciling separate records. For equipment and plant, it can establish clearer links between equipment identifiers, components and supporting documentation. For construction products and materials, consistent product attributes can make information easier to retrieve and evaluate.
Construction analytics and risk teams benefit when information can be compared across sources using more consistent definitions. ConTech applications, in turn, have a stronger data foundation to draw on when working across different project formats and systems.
A further opportunity is reuse across projects. Engineering organisations often encounter similar components, materials and technical requirements, but knowledge from previous work can remain difficult to discover when it is locked in disconnected files.
Tendering and pre-construction estimating show where this matters commercially. When past project data is structured as reusable intelligence, bidding teams can cross-reference material costs, subcontractor performance and constructability risks from comparable structural designs far more quickly. That can cut the time spent preparing a tender, and give estimators a firmer evidence base for pricing, which reduces the risk of underbidding.
When data is standardised, modelled and linked to its source, relevant information becomes easier to retrieve and evaluate for subsequent projects. It does not remove the need for engineering review or mean that previous designs can be transferred without assessment. It reduces the effort required to rediscover information and gives teams a more consistent basis for determining whether it applies.
This is also what makes the approach valuable for AI adoption. Rather than preparing disconnected datasets for each new use case, organisations can work towards reusable data structures that support different applications as requirements evolve.
Construction’s move towards AI depends on the quality of the data foundation beneath it. More powerful models cannot independently resolve inconsistent identifiers, missing relationships or unclear source context in the underlying engineering information.
Merit Data & Technology designs and implements production-grade data engineering foundations for the built environment, including KIAA orchestration pipelines that make legacy engineering information from CAD, BIM, specifications and related documents structured and queryable. The approach combines ingestion and normalisation with semantic extraction and knowledge graph construction, connecting information that would otherwise remain distributed across separate records.
This is the gap Merit works to close: between fragmented CAD and BIM silos and production AI. Extracting information is one step; preparing it for reliable reuse requires consistent representations, meaningful relationships and appropriate validation. The result is a governed, audit-ready data model that construction enterprises can rely on when AI informs decisions that affect cost and delivery.
For organisations seeking to scale AI, the priority is to treat data engineering as a core part of the adoption strategy, not as a preliminary task to be addressed separately for each application.
Construction organisations already hold substantial engineering knowledge. The difficulty is making it accessible across systems, consistent enough to analyse and structured enough to reuse.
Data engineering provides the bridge between fragmented legacy information and practical AI readiness. Through ingestion, standardisation, data modelling, validation and lineage, it helps turn disconnected records into a more coherent foundation for analytics and AI.
The opportunity extends across construction, equipment and plant, products and materials, engineering services, data and risk functions, and ConTech. Each has different requirements, but all depend on information that can be understood in context and trusted for its intended use.
The biggest barrier to AI adoption in construction is not a lack of engineering knowledge. It is the data engineering required to turn that knowledge into connected, reliable and reusable data.
Why is legacy documentation a barrier to AI adoption in construction?
Legacy documentation is spread across drawings, specifications, manuals and reports that use different formats, identifiers and units. AI applications need consistent, connected and contextualised data, so fragmented records limit the value they can deliver.
What is the difference between digitisation and data readiness?
Digitisation makes information accessible, for example by scanning drawings or extracting text from PDFs. Data readiness means the information is consistent, validated, linked to related records and traceable to its source, so it is suitable for analytics and AI.
What is data engineering in construction?
It is the work of ingesting, standardising, validating and modelling construction information from sources such as CAD, BIM, specifications and project records, so that it becomes reliable, reusable data for analytics and AI.
How do knowledge graphs help with engineering data?
Knowledge graphs represent engineering entities, such as components, materials and specifications, and the relationships between them. This lets teams query information across sources and trace everything linked to a component rather than retrieving each record separately.
Why do data lineage and revision control matter for AI?
Drawings and specifications change throughout a project. Lineage and revision handling show where information came from and whether it is current, so teams can judge if a record is appropriate for a given task and check AI-generated outputs.
Can engineering knowledge from past projects be reused?
Yes. When data is standardised, modelled and linked to its source, relevant information from previous projects is easier to find and evaluate. Engineering review is still needed to confirm it applies to the new context.
Who benefits from AI-ready engineering data?
Core construction teams, equipment and plant businesses, products and materials organisations, architecture and engineering services firms, data and risk teams, and ConTech providers all benefit from information they can understand in context and trust for its intended use.
