1. Introduction
The lack of knowledge among designers is still seen as the main issue when it comes to the untapped potential of additive manufacturing (AM) (Reference Hofmann, Ferchow and MeboldtHofmann et al., 2023; Reference Ördek and BorgianniÖrdek & Borgianni, 2025). Design for additive manufacturing (DfAM) is a term that covers knowledge around additive manufacturing. This includes methods, methodologies, tools, guidelines, etc. (Reference Pradel, Zhu, Bibb and MoultriePradel et al., 2018).
Unfortunately this knowledge often doesn’t reach practitioners (Reference HajaliHajali, 2024). The reasons for this are diverse. Novices in the field of DfAM face a bunch of challenges. These include, for example, inconsistently used terminology and definitions, a lack of guidance in certain domains and phases of product development, and difficult access to knowledge (e.g. due to poor descriptions, knowledge behind paywalls, or knowledge that is only available within a company) (Reference Celik, Elham, Erbil, Rennie and AkinciCelik et al., 2025). In the early stages of product development, which are considered to have great potential for additive manufacturing, there are also major hurdles to providing methodological support (Reference Blösch-Paidosh and SheaBlösch-Paidosh & Shea, 2022).
Another problem could be that a large part of the knowledge base is not adapted to the needs of designers, who would prefer an expert as a learning medium (Reference Obi, Pradel, Sinclair, Bibb and EvansObi et al., 2024). Entire research groups in the field of design research have been looking into how to make the qualities of experts more accessible to novices. One example is the C-QuARK method that supports novices in making the thinking and questions of experienced designers explicit by providing a set of relevant questions (Reference Ahmed-Kristensen, Wallace and LangdonAhmed-Kristensen et al., 2001). Besides finding it hard to ask the “right” questions, novices also tend to struggle with structuring their knowledge effectively (Reference Deken, Aurisicchio, Kleinsmann and LaucheDeken, Aurisicchio, et al., 2009). Artificial intelligence (AI) such as large language models (LLMs) can be beneficial for the field of DfAM by improving the provision of knowledge for novices (M. T. Reference Khan, Chen, Feng and MoonKhan et al., 2025). Those researches focus right now rather on improving technological factors such as geometric aspects like manufacturing settings (Reference Liu, Erkoyuncu, Fuh, Lu and LiLiu et al., 2025; Reference Pancholi, Gupta, Bartoszuk, Vashishtha, Ross, Korkmaz, Krolczyk and PetruPancholi et al., 2025). Little focus has been placed on improving the access to methodological knowledge the early stages of development, which are considered to have great potential for AM (Reference Liu, Erkoyuncu, Fuh, Lu and LiLiu et al., 2025).
This paper presents a concept of a framework designed to support novices in the field of DfAM in selecting, executing and implementing suitable methodological approaches in early design phases, with the help of AI.
The paper is structured in such a way that relevant topics of knowledge in DfAM are first briefly introduced. The second part of the paper derives objectives from scientific sources that the framework should fulfil. In the third part of the paper, the approach is presented conceptually, and individual aspects that have been tested prototypically are highlighted. Here, it is shown which functions can already be implemented with certainty and which questions still need to be clarified. An outlook is provided on what the next steps could look like in the attempt to support DfAM novices by replacing or supplementing an expert with an AI-supported DfAM framework.
2. Knowledge in DfAM
The transfer and provision of knowledge in the field of additive manufacturing (summarised under the term Design for additive manufacturing) is a diverse and growing field of research. Scientific papers have repeatedly addressed the task of summarising and sorting this growing but sometimes dispersed knowledge. Works such as from Reference EganEgan (2023) rather focus on particular areas in order to provide an overview of hot topics. Other contributions aim to structure, standardise, and systematically categorise this body of knowledge (e.g. Reference Berni, Borgianni, Obi, Pradel and BibbBerni et al. 2021; Reference Pradel, Zhu, Bibb and MoultriePradel et al., 2018).
However, works such as from Reference Gericke, Eckert and StaceyGericke et al. (2022) show that this need is not domain-specific. The challenges associated with the integration of methods into industrial practice are, among other factors, attributed to deficiencies in the fundamental characteristics of these. Accordingly, the authors name key aspects that are essential for enabling the effective incorporation of methods into existing processes. These insights provide valuable implications for method developers aiming to enhance the applicability and accessibility of their approaches for practitioners. While their research is primarily intended for method developers, other studies are aimed more at users and explore how methods can be integrated into the development process for designers.
The integration of methods into the development process in the context additive manufacturing has driven the development of structured frameworks and methodologies. Reference Vaneker, Bernard, Moroni, Gibson and ZhangVaneker et al. (2020), for example, has presented an approach for classifying methods and tools into three parts in the design process. Another methodology, shown in Figure 1, is based on VDI 2221 (Reference Kumke, Watschke and VietorKumke et al., 2016).
Methodological framework for DfAM based on VDI 2221 (Reference Kumke, Watschke and VietorKumke et al., 2016)
Figure 1 Long description
A diagram of a methodological framework for design for additive manufacturing based on VDI 2221. Panel A: Derivation of framework. Panel B: DfAM framework. Panel C: DfAM-specific methods and tools. Panel A shows the derivation of the framework from VDI 2221. Panel B illustrates the DfAM framework with integration types 1, 2, and 3, and synthesis. Panel C depicts brainstorming, function structure graph, general design methods and tools, AM-specific modification, characteristics of components, and positioning table. Arrows indicate the flow and relationships between different elements and processes within the framework.
Furthermore an approach suggests integrating DfAM into the process based on an agile approach (Scrum) and can be seen in Figure 2. This framework aims to help overcome the challenge of uncertainty in applying a DfAM approach. It supports users through a set of activities designed to guide them in identifying, applying, and evaluating a suitable DfAM approach (Reference Schmitt, Siewert and GerickeSchmitt et al., 2024). This framework provides the basis for the fundamental structure of the concept of an AI-supported DfAM-framework presented in this paper.
Agile DfAM framework (Reference Schmitt, Siewert and GerickeSchmitt et al., 2024)
However, such frameworks can reinforce hesitation towards using unfamiliar methodological approaches, if they represent another hurdle to the accessibility.
Novices prefer to overcome such hurdles in the field of DfAM with the help of experts (Reference Obi, Pradel, Sinclair, Bibb and EvansObi et al., 2024). One response from design research in the field of DfAM to this need was the development of expert logic for providing relevant knowledge. Traditionally ontology-based, these approaches increasingly integrate AI to overcome limitations and facilitate natural language interaction for novices (e.g. Reference Schaechtl, Goetz, Schleich and WartzackSchaechtl et al., 2023). The large language models (LLMs) frequently used here sometimes exhibit the phenomenon of presenting false facts as truth in a plausible manner (so-called hallucinations). This can be counteracted by a defined database and instructions on how to handle knowledge (Reference Li, Zammit and FrancalanzaLi et al., 2025). In such knowledge injection, the two approaches of Retrieval-Augmented Generation (RAG) and Fine-tuning are worth mentioning. One key difference is that fine-tuning requires training on data, whereas RAG keeps knowledge external and accesses it at runtime (Reference Ovadia, Brief, Mishaeli and ElishaOvadia et al., 2023). In some cases RAG and Fine-tuning is combined (e.g. Reference Chandrasekhar, Chan, Ogoke, Ajenifujah and Barati FarimaniChandrasekhar et al., 2024). Reference Li, Zammit and FrancalanzaLi et al.’s (2025) approach uses RAG and combines its advantages with those of knowledge graphs to help novices access complex DfAM knowledge. However, most AI based approaches focus more on topics like the possibilities for technological knowledge (e.g. Reference Khan, Chen, Feng and MoonKhan et al., 2025), printing parameters (e.g. Reference Li, Zammit and FrancalanzaLi et al., 2025), or decision-making in smart manufacturing (e.g. Reference Wang, Zhang, Jiang and LiWang et al., 2025).
Approaches aimed at the targeted provision of DfAM knowledge, particularly for the early phases of product development, remain underrepresented. Despite all the enthusiasm surrounding the rapid advances enabled by AI, it should not be overlooked that the way designers interact with AI has a significant impact on the quality of the results (Reference Rani, Jining, Shoukat, Shoukat and NawazRani et al., 2024). This aspect in particular, should be carefully considered by those who seek to integrate AI into their development processes, whether for the development of products, or methodological approaches.
3. Objectives for an AI-supported DfAM-framework
This section describes a set of objectives and requirements that should be considered when developing an AI-supported DfAM framework for supporting novices in the field of DfAM by making related knowledge better accessible. By deducing the search domains (according to Reference Blessing and ChakrabartiBlessing and Chakrabarti, 2009), three theoretically relevant groups of perspectives were derived (see Table 1). Group 1 addresses general requirements for methods and methodologies, as well as the way these should be documented to reach a broader acceptance. These requirements and the objectives derived from them are relevant both to the development of the framework itself and to the presentation of the proposed methodological approaches. Group 2 sets objectives for expert systems. Group 3 presents the objectives for expert-novice interactions.
A targeted literature search (according to Reference Arksey and O’MalleyArksey and O’Malley, 2005) was conducted for each domain in SpringerLink, ResearchGate, and Google Scholar. Search terms included “design method requirements,” “expert system design principles,” and “novice expert interaction design.”
Both backward snowballing and forward snowballing (described in (Reference WohlinWohlin, 2014)) was carried out for relevant articles. Requirements, criteria, and principles were extracted from those identified sources, checked for redundancy, and clustered formulated as objectives. These objectives can be seen in the following table.
List of objectives
4. AI-supported DfAM-framework: a concept
Based on the various objectives presented above, a concept for an AI-supported DfAM-framework will be introduced. The fundamental functionality of this framework is explained and selected components are prototypically tested. The framework consists of four principal elements (see Figure 3): (A) a process model derived from an agile DfAM Framework (see Figure 2), (B) the framework’s user, (C) an AI-supported copilot that assists activities, and (D) the knowledge databases that control the workflow of the framework, provide domain-specific information and contextual support.
4.1. BPMN for AI supported DfAM-framework
The conceptual model is represented at the process level using Business Process Model and Notation (BPMN). BPMN provides the basis for good understandability for collaboration, even with more complex processes. For this purpose, there are implementation guidelines that are taken into account here (Reference Corradini, Ferrari, Fornari, Gnesi, Polini, Re and SpagnoloCorradini et al., 2018). The four main elements described in the previous section are represented in the BPMN as lanes (A–D). Events are modelled as circles, while gateways for representing decision or parallel activities are modelled as diamonds. BPMN provides differentiated semantics for triggers, wait states, timeouts and error paths, making it particularly suitable for mapping a multi-layered, AI-supported framework. Sequence flows indicate the logical sequence of activities within a process and are represented by directed arrows. Information flows between participating actors or lanes are modelled as dashed arrow lines. A communication scheme based on a grid has also been introduced for precise referencing of individual process steps. Lanes are labelled as a letter sequence (A–D) and columns of the grid are numbered consecutively.
Lane A: agile framework
Lane A serves as an orienting element that replicates an agile DfAM framework (see Figure 2). This framework is used because the interaction between user, AI copilot, and database is not expected to follow a strictly sequential logic but instead reflects the iterative character of agile development. Its terminology and structure are adopted from the agile approach described in (Reference Schmitt, Siewert and GerickeSchmitt et al., 2024) which enables conceptual comparability even though the elements deviate from BPMN notation. Lane A does not directly interact with the other lanes.
The lane comprises several stages: project criteria (user- or company-defined requirements), AM capabilities (opportunistic identification/representation of AM potentials), and the selection of a suitable DfAM approach. The subsequent DfAM sprint is modelled as a subprocess (white frame) and includes planning, implementation, and testing. An iteration loop allows repeated sprints or a change of approach if goals are not met. The resulting outputs vary depending on the selected method (e.g., models or conceptual solutions). Once a plan is successfully realised, the outcome is reviewed by identifying the AM capabilities applied and evaluating their alignment with the original project criteria.
Lane B: beginner (user)
Lane B represents the activities of the user, a novice in the field of DfAM. In line with the lane letter (B), the lane is designated as “Beginner”. The user initiates the process through a start event and subsequently engages in a dialogue with the AI copilot. During this interaction, the user provides information regarding the current status of the project in which AM is being considered, as well as their position within the framework. For instance, if an approach (DfAM) has already been selected, the user may jump directly to the AI-assisted steps related to method selection and proceed directly to the subsequent phases. In case of an initial application of the framework, the user explores one or more DfAM approaches suggested by the copilot. This is followed by a DfAM sprint, during which the selected approach is tested within a time-boxed iteration. The process concludes with an evaluation phase, which not only assesses the outcome of the sprint but also determines whether the applied DfAM approach represents a suitable one for continued development.
BPMN of the AI-supported DfAM-framework
Figure 3 Long description
Panel A: The flowchart begins with the Agile Framework, which includes six steps: Project criteria, AM capabilities, Design support selection, Plan, DfAM sprint, and Plan reached. If the plan is not reached, it loops back to the Plan stage. If the plan is reached, it proceeds to Output and then to Review. Panel B: For DfAM Beginners, the process starts with taking control of interaction with the user. It then involves answering copilots questions, becoming familiar with the DfAM approach, running a DfAM sprint to generate output, and evaluating the result. Panel C: For Copilot AI, the process starts with taking control of interaction with the user. It then involves questioning about project status, showing opportunities, suggesting design support, giving details, providing planning and application, helping analyze the result, helping derive insights, and supporting possible implementation. Panel D: The database supports the framework with guidance of interaction, framework process and user location, DfAM repository, and support of DfAM sprint and evaluation.
Lane C: copilot
By starting the framework, the user activates the AI copilot, which then takes over the control of the interactive guidance of the process and navigates the user through the framework. The copilot adapts its suggested support to the user’s profile, such as design intent, prior experience, and project status, and provides context-specific recommendations. Although the following description focuses on first-time use, all activities can also be executed individually to avoid redundant steps. At the beginning, the copilot assesses the user. Users who have already completed product architecture development are not the primary target group of the framework. However, they may still benefit when planning to integrate DfAM into future projects. The copilot then introduces relevant AM capabilities and initiates a two-stage support process: (1) identifying suitable DfAM methods and (2) providing contextualised guidance and explanations for their application. It also references sources (e.g. scientific literature) and responds to user enquiries. During the DfAM sprint, the copilot acts more supportive and in a less directive role, offering planning assistance, decision support, and adaptive feedback. A similar level of guidance is provided during the evaluation phase, particularly in reflecting on the process, interpreting results, and assessing their accordance with project objectives.
Lane D: database
The database describes external data sources that ensure the functionality of the framework on several levels. With regard to the handling of the framework, guidance for the interaction between copilot and user must be defined. This requires an assessment of the user, e.g. what previous experience or prior knowledge they have and what their intentions are. Another aspect of handling the framework is controlling its sequencing. This includes the sequence of active and passive roles of copilot and user in the respective process phases of the framework, the orientation of the user in the framework and the entry point allocation. At a subject-content level, it must be ensured that a DfAM repository contains relevant knowledge and that this content can be communicated correctly by the copilot. Finally, the database must provide the basis for supporting the user in their specific activity in the application and evaluation of an applied DfAM approach. Limitations of the knowledge base for the entire framework (e.g. with regard to the DfAM repository or domain-specific knowledge) must be clearly communicated in order to strengthen confidence in the framework.
4.2. Prototyping on database (D) and copilot (C)
This section presents an initial feasibility study on how the interaction between the lanes can be realised. An assessment of the criticality of the functionalities (according to Reference Zorn, Glaser and GerickeZorn, Glaser, and Gericke, 2024) helped to determine the prototyping sequences, with the result that the focus was placed on the activities in column one of the BPMN and the first three elements of the lane database (D). (“Guidance for interaction”, “Framework process and user location”, and “DfAM repository”). Various aspects of the objectives and related functions are tested during the prototyping. This prototype is based on a self-configured GPT that was implemented with ChatGPT-5.
Figure 4 shows the basic structure of the GPT. Main elements can be seen on the left side. The GPT uses an external database to provide domain-specific information to the LLM similar to a Retrieval-Augmented Generation (RAG) approach. Two different types of injected knowledge are distinguished. The conversation is defined in a central configuration file (FLOW.json). This file format is suitable for data exchange and data transfer between different programming languages. In this case, the file was created with Visual Studio and is based on a decision tree consisting of many nodes, each representing a decision in the dialogue and all having the same structure. Each node has an output from copilot to the user (prompt), an expected response type (type), possible response options (options), transitions to the next node (edges) and a safety net (fallback_to). The second type of injected knowledge is subject content. This includes scientific sources, which are summarised here as “KNOWLEDGE.pdf” (this could be scientific articles and textbook). Initial tests were conducted with a maximum of three papers in the knowledge database in order to make the answers comprehensible. In addition, this type of architecture has a limitation of around 20 papers. The GPT instructions define rules that control interaction. Here, for example, it was specified that only one question should be asked of the user before it is answered. It was also prescribed that only knowledge content from the injected database (KNOWLEDGE.pdf) may be used by the LLM. This allows developers of such frameworks to determine which knowledge content is relevant and may be used. The FLOW.json file was specified to the GPT here in order to steer the conversation according to the decision tree. STATE information serves as a guide to where the user is currently located in the decision tree and how they got to that point. The GPT instructions control the interaction between the user and the copilot as described.
Customised GPT as a prototype test for use as an AI copilot
5. Discussion and outlook
The prototyping phase showed that that initial internal test runs of the configured GPT appear promising of performing several of the tested functions within the proposed concept of an AI-supported DfAM framework. This section discusses the key findings, identifies objectives that remain untested, and outlines future steps required for the comprehensive development of the framework.
Within the feasibility study, a prioritisation was conducted to identify those functionalities whose absence would critically affect the framework’s core operation. Consequently, less emphasis was placed on testing objectives related to user communication and training (see objectives 1.1–1.6). A deeper investigation of these aspects was considered premature, as the required infrastructure for user interaction was not yet available. Furthermore, formulating definitive claims regarding the framework’s overall effectiveness would be inappropriate at this stage, as such validation can only be achieved once the final system is implemented. With respect to the objectives in Group 1 (see Table 1), the results confirmed that GPT can extract method-related information from documents when such information is present. Interaction with the knowledge base further demonstrated that users were able to ask content-related questions to which GPT responded with appropriate depth and complexity according to the user’s level of expertise. This confirms the fulfilment of objective 3.2. Moreover, the separation of the knowledge base from other framework components (e.g., configuration files or system instructions) enables a modular architecture, allowing for flexible adaptation and future extension (objective 2.4). The structured conversational logic, defined by the configuration file in combination with GPT instructions, further confirmed the feasibility of several design objectives. The predefined response options establish structured conversation techniques (objective 3.1), support the contextual positioning of users within the process (objective 2.5), and ensure the reproducibility of results under identical input parameters (objective 1.7).
Nevertheless, several aspects remain unresolved, particularly those concerning validation and verification. The validation of results achieved through the methodological approach currently exists only at a conceptual level. Similarly, the verification and validation of the expert system (objective 2.1) could not yet be carried out for the framework in its entirety. Due to the limited capacity of the GPT for external knowledge documents and increasing processing time as the number of documents grows, it is expected that multiple GPTs will be needed to ensure functionality and quality. This is supported by the fact that this is not really RAG, as the knowledge content is not externally chunked and prioritized (Top-K). Quality and contextual adequacy of the AI copilot’s recommendations for supporting users during DfAM sprints warrant further examination. Another open issue concerns the integration of the GPT-based modules into the complete framework. This includes ensuring both the technical interoperability and seamless communication between modules as well as the design of the user interface and overall system accessibility. Currently, GPT can be accessed privately, shared via link, or published through the GPT Store. However, aspects of data privacy, retention, and handling have only been addressed superficially. Regarding updatability, further research is required to determine how a dynamic and continuously evolving knowledge base can be implemented. Importantly, within the feasibility study, no major obstacles or showstoppers were identified that would hinder the continued development of the proposed framework. The concept therefore appears technically and methodologically feasible, and its further exploration is strongly recommended to validate its scalability, robustness, and applicability in real design environments.
In the next phase, the prototype should be advanced to a maturity level suitable for empirical user evaluation. This evaluation should focus on assessing functionality, usability, and the interaction between human and AI, in order to identify opportunities for optimisation. Such validation will enable the proposed framework to reach its full potential in facilitating novice access to DfAM, thereby contributing to a more systematic and effective exploitation of the opportunities offered by AM.
Supplementary material
Overview of GPT structure and outcomes: https://pascallacsap25.github.io/DfAM-custom_GPT
Open access
