Research question:

What are the relevant use cases for structure-based searches in adaptation design, and how can these be implemented easily from a technical perspective?

3.1. Use cases for structure-based similarity searches

The generic use case and definition of structure-based similarity searches in this article is to find all assemblies in the PDM/ERP system for which the search criteria extend across more than one entity referenced by the searched structure. This occurs on a daily basis in adaption design when searching through where-used lists, parts lists, classification schemes, functional and other product structures, as illustrated in Figure 1. This basic application can be found not only in adaption design, but also in related areas of product development. In addition, product structures are even regarded as the core of searches in product development in general (Reference Jones, Matthews, Xie, Gopsill, Dotter, Hicks, Maier, Škec, Kim, Kokkolaras, Oehmen, Fadel, Salustri and Van der LoosJones et al., 2017, p. 43).

Figure 1.

Basic principle of structure-based search — the element being searched for is inferred from characteristics of referenced elements cf. Reference Krüger, Saske, Schwoch, Paetzold-Byhain, Krause, Paetzold-Byhain and WartzackKrüger et al. (2023)

Table 1 provides a brief overview of the individual use cases derived from the generic use case and frequently encountered in practical application in adaptation design, in order to provide a first understanding of the problem situation and to enable a comparison with the state of the art in the following section 3.2. The list does not claim to be exhaustive, but contains relevant use cases that occur on a daily basis in customization design in the construction industry or in plant engineering. Detailed examples can be found in the implementation demonstration in section 3.3.

Table 1.

Individual use cases in adaption design

3.2. State of the art for searching in PDM/ERP systems

Modularization and classification are the established methods for providing structure-based information at the assembly level (cf., among others, Reference Adamenko, Hooshmand, Kunnen and KöhlerAdamenko et al., 2017). However, due to the high maintenance costs involved, this cannot be done consistently in plant engineering and adaption design (Reference DüsselmannDüsselmann, 2008, p. 42ff.).

Common PDM/ERP systems rely on object-relational databases in which product structures are stored in tabular form, and search queries are based on SQL. SQL can be used also to resolve structures, e.g., via “Common Table Expressions” (CTE), “Runtime Query Recursion,” and “Joins and Aggregate Functions” (Reference Ferrari and PirozziFerrari & Pirozzi, 2020). But, this has some limitations.

Structure-based searches in relational data are performance-intensive at runtime, as a large number of tables usually have to be queried in sequence, that is why index creation is necessary (see Reference BeaulieuBeaulieu, 2009). Both the queries and the indexes in SQL are rigid and case-specific – and cannot be easily modified for new query constellations, such as searching across multiple structure levels instead of just one. Graph matching – which would correspond to the mapping of searched substructures onto a target structure required for adaptation design – consumes very high performance when technically mapped as a keyword search in relational data (Reference Khan, Ranu, Zomaya and SakrKhan & Ranu, 2017, p. 543).

Fuzzy and similarity searches in higher-dimensional data can only be SQL-implemented with extensions to enable a comparison of “similarity measures” via vectorization of input data (cf. Reference Lu, Hou, Yan, Zhang, Du and MoscibrodaLu et al., 2017, Reference Nandy, Dong and Goucher-LambertNandy et al., 2021). But as explained, similarity searches are necessary in addition to structure searches, as it is only in the rarest of cases that exactly matching substructures can be found, the primary aim is to find at least similar ones.

The only widespread application of structure-based searches in the PDM/ERP environment is geometric similarity search in CAD data (e.g., Reference Bookhahn and NeumannBookhahn & Neumann, 2023). Comparable to image searches on the web, these are based on the indexing of patterns and properties contained in the geometry. There are also applications in bioinformatics for identifying molecular structures (e.g., Reference Nag, Baidya, Mandal, Mathew, Das, Devi and KumarNag et al., 2022). For non-geometric artifacts in PDM/ERP systems, structure-based retrieval methods have so far been little or not at all developed (cf. Reference Han, Zhang, He, Ba and YuanHan et al., 2023).

In summary, implementing structure-based similarity searches with relational database management systems requires considerable effort for feature extraction from the data, access methods (search trees and indexes), and queries (see also Reference Eleutério, de Oliveira, Teixeira, Vespa, Silva, Traina and TrainaEleutério et al., 2025, p. 971f.). In addition, there are increasing conceptual doubts as to the extent to which relational algebra is fundamentally suitable for creating efficient structure-based queries in general (Reference Khan, Ranu, Zomaya and SakrKhan & Ranu, 2017, p. 575).

Another approach would be using large language models (LLMs), and providing only the relational data from the PDM/ERP system. Due to their neural architecture, language models appear to be better suited for structure-based similarity searches and are already being used in neighboring domains, especially when searches are to be performed not only on the basis of geometry or time series, but also in high-dimensional data sets (cf. Reference Park and MelkotePark & Melkote, 2026). Indexing can be carried out automatically and, over the time, the model can take into account “learned” facts and constraints, which is very helpful for recommendation (Reference Joshi, Joshi, Syed, Vijayarani, Kumar and NavalJoshi et al., 2024). Another (known) advantage of LLMs is the “natural language processing.” Search queries do not have to be declared in a specific syntax, but can be formulated directly by the users (cf. Reference Gantayat, Saha, Sen, Mani, Dey, Chaudhury, Krishnapuram, Singla and RoyGantayat et al., 2019).

Existing web and enterprise searches to retrieve documents and metadata are increasingly being used in product development in general (cf. Reference Xiao, Zheng, Leng, Gao, Fu and HongXiao et al., 2024), adequate applications and procedures for PDM/ERP environment and product structure data are still lacking (Reference KraheKrahe, 2022, p. 153). But the ability of LLMs to extract, index and query structures independently – and to communicate in natural language appears to be well suited to a simple implementation of structure-based similarity searches for adaption design, especially since previous implementation concepts still require a great deal of effort for index creation (cf. Reference Krüger, Saske, Schwoch, Paetzold-Byhain, Krause, Paetzold-Byhain and WartzackKrüger et al., 2023). This would make it easier to extract more information from PDM/ERP data and significantly support the search for and integration of existing solutions in product development of plants and the solution business for customer-specific products.

In the following chapter, a feasibility study and examples will therefore be executed to compare the extent to which a large language model is capable of implementing the use cases of structure-based searches in adaption design. The focus here not will be on AI-specific issues such as comparisons between language models, etc., but explicitly on verifying whether a language model can solve the use cases in principle.

3.3. Concept verification with an initial prototype

The Feasibility was verified using ChatGPT 5.0 with the model GPT-5 mini. To do this, the respective sample assemblies were first introduced to the language model as CSV runtime objects, and then relevant questions were asked about the use cases to assess whether the language model is capable of doing this. Upstream training or company-specific adaptation was deliberately not carried out in order to be able to directly assess the functionality in relation to the use cases.

1. a) Complex where-used list

To illustrate the first use case, Tables 2, 3, and 4 show product structures (in the form of parts lists for fictitious assemblies A, B, and C) that contain one or more “pumps.” In the first step, a where-used list is used to identify these assemblies by searching for “pump.” By searching the structures in the second step, it can then be determined that assemblies A and B, but not assembly C, also contain a valve, and are therefore potentially suitable for the above-mentioned task.

Table 2.

Example assembly A

Table 3.

Example assembly B

Table 4.

Example assembly C

If the search in common PDM/ERP system is to be expanded to include a variation in characteristics, e.g., to run through several pump types, it becomes almost impossible to achieve the desired result with reasonable effort, even in this simple constellation. Comparing more complex patterns of assemblies or PDM databases with thousands of assemblies, cascading structures or including other element types like functional structures is unthinkable then. This results in the requirement to be able to fall back on an index or automaton that contains this information or can resolve it on the basis of a search query (cf. Reference WeberWeber, 2011, p. 79ff.). The LLM in the above example configuration is able to answer the question in one step, as shown in Figure 2 on the left.

Figure 2.

Structure-based similarity searches with LLM are fundamentally feasible (left), but fails in case the semantics of specific terms have not been trained (right)

This means that the generic use case of structure-based similarity searches across more than one entity referenced via the structure – in this case, across several parts within a building structure – can be implemented easily in principle and in practice using a language model. In addition to “AND,” questions with the logical operators “OR” and “NOT” are also answered correctly.

1. b) (Automatic) classification of assemblies

Compared to the bill of materials analysis introduced in use case 1, classification places higher demands on technical implementation in the PDM/ERP system. On the one hand, each element can be assigned to several feature trees, such as geometry, material, manufacturer, product group, standard, etc. On the other hand, the formation of generic terms leads to ambiguities, for example, the differences between a “sheet” and a “plate” – or between “stainless steel” and “high-grade steel.” In both cases, the search engine is expected to be capable of abstraction (see Reference GraupmannGraupmann, 2006, p. 15f.).

The mechanical assemblies A, B, and C considered at the outset, as well as the electrical assembly D newly introduced in Table 5, once again highlight the application case of the classification. There are various order-specific material specifications for the parts contained. If a different classification is requested for the design in the customer project, for example, according to “structural steel” and “stainless steel,” “conductive” and “non-conductive” or “heat-treated” and “corrosion-resistant” materials, this must be done manually as in application case 1 – or a separate classification scheme must be set up and maintained for each requested list.

Table 5.

Example assembly D

This also highlights the need for technical support for the process. In addition to indexing according to the required characteristics, it must also be possible for companies to influence the criteria used to determine whether assemblies are included in a specific characteristic tree. Looking again at Table 5, this can be seen in the material specification “St” for the angle iron. Whether this refers to steel or stainless steel cannot be determined by a machine and must be defined by the user, for example, by referring to the relevant data sheets.

To verify the second use case, the language model is asked to list the parts contained in the assemblies separately according to “structural steel” and “stainless steel.” This question was answered correctly for the most part. This means that the functionality of (automatic and semantically correct) generic term formation is fundamentally ensured by the application of an LLM. Another test with the task of classifying the assemblies into “mechanical” and “electrical” also had a positive outcome.

In the example carried out, however, the assignment of the material “A2K” (screw in assembly E) to the category “stainless steel” was incorrect, as can be seen in Figure 2 on the right. Although the conclusion “A2 equals stainless steel” is correct in itself, “A2K” refers to (blue) galvanized structural steel, which is a common notation for standard parts. As already explained, monitoring and, if necessary, adjustment of the assignment to company-specific terms must always be provided in practical application in order to avoid incorrect assignments.

1. c) Prioritized search result lists and suggestions

This use case can be understood by referring to the assemblies A, B, C, and D introduced in Tables 2 to 5. Further examples include “List all assemblies that contain about half a meter of pipe” or “Show all assemblies that contain more than 1 kg of brass” where the hits are to be sorted by similarity in order to make a selection decision. An option to choose whether character strings and parameters are to be interpreted exactly or whether a dictionary of synonyms or typical deviations is to be used should be available independently of this and, as in use case 2, should be defined company-specific.

For verification purposes, the question “Which assembly is most likely to contain 0.45 m of pipe?” was asked in the above ChatGPT prompt. The question is answered correctly and the sorting is also correct according to the specification of the search query. However, a further query regarding the degree of corrosion protection (“Which assembly is potentially least protected against corrosion?”) could not be represented in a meaningful ranking using the initial data, as shown in Figure 3 on the left.

Figure 3.

Restrictions on sorting capability based on qualitative data (left), (automatic) system integration — excerpt from complex example (right)

A critical assessment of the results shows that, in order to establish valid similarity measures from qualitative data for sorting purposes, more training data is required on the one hand, and company-specific definitions of feature combinations on the other.

1. d) (Automatic) system integration

In the case of the above example with the pump and the valve, if the structure-based similarity search also specifies the neighboring elements (e.g., “interferes with flange 0815”), the range of results should be filtered accordingly, annotated with notes, or, if alternatives are available, these should be automatically played through, based on defined preferences or exclusions (e.g., if flange 0815 should only be combined with certain pumps). To illustrate use case 4, assembly E is introduced in Table 6 in addition to the examples shown above (assemblies A, B, C, and D).

Table 6.

Example assembly E

Assembly E, for example, is a piping adapter whose connectivity to one of the existing assemblies is to be tested. To do this, the flange must come from the same manufacturer as the pump to which it is to be connected. Assemblies B and C would be suitable, as they contain a pump from the same manufacturer; assembly A is ruled out because it is from a different manufacturer. On the other hand, the maximum system pressure of 10 bar at the adapter (assembly E) must not be exceeded by the pump unit. This also eliminates assembly B. Assembly C remains and can be used as a template adaptation design.

For verification purposes, the scenario was played out in the chat with the question “To which assembly can assembly E possibly be connected if the pump must not come from another manufacturer?” As a result, assemblies B and C are correctly identified as possible candidates, as they each contain a pump from the same manufacturer. Here, an obstacle built into the example, namely the inconsistent spelling of “Company 21,” was also resolved. The additional clarification “The pressure defined on the adapter must not be exceeded by the pump unit” was also interpreted correctly. On the one hand, assembly E with the flange is correctly interpreted as an “adapter,” and assemblies A, B, and C with the pumps are interpreted as a “pump unit.” On the other hand, the interpretation of “10 bar,” “7 bar,” etc. as pressure values and the comparison based on them are also correct. Figure 3 on the right shows the result determined by the LLM from the sample data and inputs provided.

3.4. Summary and discussion of the results

The results of the feasibility study on the extent to which a language model can be used as a search tool (operational readiness, OR) are summarized in Table 7. The key advantage of using LLM compared to conventional search is that the generic use case (“find all assemblies where the search criteria extend over more than one entity referenced by the searched structure”) can be implemented immediately. This eliminates the need for manual searches or index creation. The disadvantage is that the (assembly) data must be made accessible to the LLM, which will be discussed in more detail in chapter 4.

Table 7.

Evaluation of LLM use

Other use cases can be implemented with restrictions. During classification, not all specific spellings are recognized and may be assigned to incorrect categories; similarity searches only work reliably for quantitative characteristics. In both cases, training of the LLM will be necessary in order to achieve reliable results. Measured against the effort required for manual classification, the possibility of automation is nevertheless seen as an advantage overall. The target hypothesis using the language model to easily implement structure-based similarity searches is thus confirmed. This also essentially answered the research question. Since the focus was on feasibility as such, an in-depth comparison of the behavior of different language models, statistical evidence of reproducibility, and systematic studies on further use cases will have to be carried out at a later date due to the scope of this study.

For system integration application (use case 4), it should be noted that in the examples provided, the LLM has simply “guessed” some combinations, which are not necessarily relevant at the component level. Therefore, company-specific training or the specification of permissible feature combinations must first take place before a language model can actually perform system integration tasks.