Mathematical Decision Layers for Technical Proposal Generation in Industrial Electrical Houses Using Generative AI

Abstract

Industrial electrical houses are engineered systems that transform and control electrical power to supply industrial loads. Preparing technical proposals for these rooms requires consistent engineering choices across multiple artifacts while drawing from heterogeneous client documents, historical projects, and supplier catalogs. This paper reports an industrial prototype that integrates generative AI, system modeling, and mathematical decision methods to support that workflow. We represent requested outputs as ordered sequences of functions and link those functions to candidate equipment blocks through functional and physical graphs that enable traceable retrieval and reuse. Using this representation, we compute a minimal internal-cost baseline by solving a mixed-integer assignment model with sizing constraints, and we rank technically feasible alternatives using fuzzy DEMATEL to derive criterion weights and TOPSIS to obtain an overall ordering under multiple criteria. The workflow is illustrated with an example and the prototype tool used in a company operating in Chile, Peru, Ecuador, and Bolivia, where document ingestion and equipment-list extraction are integrated with human validation. The results illustrate how structured representations, optimization, and multi-criteria ranking can support auditable configurations for engineering review and commercial selection.

1. Introduction

Generative AI has seen significant advances and introduces both opportunities and competitive pressures across multiple domains, particularly in industrial production and commercial processes. In this paper, we focus on the automation of engineering design and technical proposal development for electrical houses (or electrical rooms or E-houses) using generative AI.

Electrical rooms are essential facilities for industrial companies that operate equipment that requires controlled electrical power. Their role is to provide production facilities with a reliable and controlled energy source; this is achieved by transforming power from high voltage to medium or low voltage levels, followed by control and reliability stages that enable the supply of downstream industrial loads. In Figure 1, as an illustrative example, we show an electrical room serving mining operations or other industrial sectors, supporting motor controllers, variable frequency drives, reactive power equipment, power distribution panels, and lighting systems, among others.

Although the design process for electrical rooms varies between companies, it typically follows a common sequence of steps. These include receiving client requirements, interacting with the client to define a preliminary design, collecting information from equipment, component, and service suppliers to configure a client-specific solution, and finally delivering a formal technical proposal. This proposal constitutes a comprehensive package including engineering design, single-line diagrams, physical layout, a detailed bill of materials with pricing, and all formal documentation provided to the client.

Figure 2 shows the workflow for the engineering design and technical proposal of electrical rooms. The diagram illustrates the end-to-end process starting from customer requirements (RFP), moving through the engineering design phase (including equipment sizing, development of electrical single-line diagrams (SLDs), and general arrangement (GA) layout organization), and culminating in the delivery of a complete technical offer, including detailed SLDs, equipment lists (BOM), and formal proposal documentation.

The improvement potential enabled by generative AI has gone beyond isolated developments toward systematic organization of dedicated teams aimed at increasing operational efficiency. As a result, this opportunity has effectively become a competitive pressure. Companies are increasingly competing to deliver more accurate designs and proposals in shorter time frames. This not only improves solution quality while reducing time and cost, but also increases the number of technical proposals that can be issued. When combined with higher productive capacity and growing markets, this dynamic can lead to significant growth for firms that adopt these technologies, to the detriment of those that delay their adoption.

With the emergence of LLM-based tools such as ChatGPT (GPT-5.2) and Gemini 3 Flash, project engineers began to use these technologies in an unstructured manner to support their daily work. The results were mixed. Although certain tasks within the workflow could be completed more quickly, the high frequency of errors in designs, technical specifications, and equipment pricing led to review processes that were comparable to, and in complex cases longer than, those of fully manual workflows. This experience motivated a structured initiative that involved collaboration between a university and an internal company development team, aimed at guiding the transformation process in an organized manner and capturing the benefits that were not achieved during the initial unstructured adoption.

The design and technical proposal process for electrical rooms can be automated using generative AI. The main challenges include identifying critical stages of the process, defining a mathematical and data model that supports scalability toward later design and construction phases, and ensuring the sustainable use of tools that do not become obsolete due to interface changes, do not require excessive maintenance, and are able to improve progressively through continued use. For the present quoting stage, this choice is also practical. Preferences are often available only as qualitative judgments from a small engineering panel, so estimating probabilistic distributions or formulating a richer stochastic multi-objective model would add complexity without proportional operational benefit. The DEMATEL-TOPSIS combination provides a lightweight way to incorporate expert judgment and compare multiple technically feasible alternatives, whereas a purely cost-based model would return only a single baseline solution.

On the decision-analysis side, multiple-attribute methods have long been used to rank alternatives under expert uncertainty; for example, spherical fuzzy TOPSIS variants have been applied to manufacturing-system and related selection problems [1,2]. Recent TOPSIS-related work has also extended the method toward cloud-based probabilistic hesitant fuzzy multi-criteria sorting in medical insurance fraud [3]. That study addresses a sorting/classification problem under probabilistic hesitant fuzzy uncertainty, whereas our paper uses fuzzy DEMATEL–TOPSIS as a downstream ranking layer for technically feasible industrial electrical-room proposals within an end-to-end workflow that also includes retrieval, graph-based system representation, and baseline cost optimization. In our setting, therefore, the main issue is not the standalone use of a ranking method, but its integration with retrieval, system representation, and proposal generation.

Figure 3 shows the architectural schematic of our multi-agent Retrieval Augmented Generation (RAG) pipeline we designed to automate the generation of technical proposals for electrical infrastructure. By implementing specialized retrieval agents and a centralized Router Agent, the system effectively bridges the gap between unstructured customer requirements and disparate vendor databases. The integration of semi-automated engineering inputs ensures that the final output follows industrial standards, maintaining numerical precision and structural integrity in the resulting technical documentation.

In this paper, we describe the development of an AI-driven design and proposal process for electrical rooms in a company operating in Chile, Peru, Ecuador, and Bolivia. The analysis emphasizes the role of system-level thinking and mathematical modeling as key enablers of a successful implementation. We do not claim this to be the only possible approach, but rather show how the company transitioned from a semi-manual process with unstructured AI usage to a more automated workflow, with the objective of lowering lead times, reducing costs, and improving accuracy in the design, layout, and pricing outputs of the final proposal. The relevance of a systems and mathematical modeling perspective is important for the successful industrial deployment of such systems.

Our system is a multi-agent RAG pipeline whose data organization is driven by an explicit systems modeling step. We structure and index embeddings using a functional and physical graph representation of electrical rooms, so retrieval follows the underlying engineering decomposition rather than an ad hoc document taxonomy. Beyond information retrieval and drafting, the pipeline includes two mathematical layers that are central to proposal generation in this domain. First, it solves an internal cost-based optimization problem to produce a minimal-cost technically feasible baseline proposal. Second, it generates multiple technically feasible proposal alternatives that may not be preferred by the client and may not be feasible under vendor exclusivity clauses, but are valuable as design and commercial options. These alternatives are ranked with TOPSIS to support commercial decision-making and strategic selection. In this sense, the paper’s main contribution is not only the use of agent RAG components, but the explicit integration of systems modeling, graph-based representation, cost optimization, and multi-criteria ranking within a single end-to-end industrial workflow.

The remainder of the paper is organized as follows. Section 2 reviews recent work on RAG and multi-agent systems in industrial settings, with emphasis on architectural choices, retrieval and representation strategies, and practical deployment requirements. Section 3 formulates the technical proposal workflow from a systems perspective and motivates the need for an explicit structure before automation. Section 3.2 introduces a functional and physical graph representation of electrical rooms and explains how this representation organizes the data model and retrieval process. We then present the mathematical decision layers that operationalize proposal generation: Section 4 defines a cost-based optimization model that produces a minimal-cost technically feasible baseline, and Section 5 introduces a TOPSIS-based multi-criteria ranking to select among technically feasible alternatives when cost is not the only relevant dimension. Section 6 reports an illustrative industrial example that integrates the graph representation, the cost model, and the TOPSIS ranking, complemented with representative system outputs. Finally, Section 7 summarizes the main contributions and outlines limitations and directions for future work, including the role of informal internal feedback and the need for more systematic evaluation.

2. Literature Review

This section reviews recent work on retrieval augmented generation (RAG) and multi-agent variants that are relevant to automating engineering design activities and technical proposal development. The emphasis is on architectural patterns, retrieval and representation strategies, transparency and auditability mechanisms, and evaluation practices that matter when outputs must be numerically correct, traceable, and usable in operational settings.

2.1. Scope and Limitations of the Review

We restricted the literature search regarding AI to the period from 2021 to 2026 because multi-agent RAG, AI, and industrial applications of RAG have advanced rapidly in this window. Broad surveys and systematic reviews provide a useful baseline for organizing the design space, including techniques, metrics, and recurring challenges in RAG systems [4,5]. Work focused on explainable agentic RAG further highlights that interpretability and accountability have become first-order requirements as these systems move toward higher impact decisions [6].

A second boundary is topical. Direct literature on electrical rooms (or E-houses) and end-to-end proposal automation is limited, so we expanded the scope to adjacent industrial engineering and engineering services contexts where similar artifacts and constraints appear. These include engineering knowledge retrieval supported by knowledge graphs [7], interactive industrial knowledge management [8], and domains in electrical engineering where standards and structured technical knowledge are central [9,10]. The objective of this expansion is not to claim equivalence between domains but to use the closest available evidence for tasks that resemble the core workflow in this paper (requirements interpretation, equipment selection and sizing, document and standards retrieval, and structured outputs such as equipment lists and supporting documentation). At a broader industrial level, adjacent studies also examine technology adoption and diffusion under network and policy drivers. For example, Cheng et al. [11] analyze the diffusion of flexibility-transformation technology among thermal power enterprises using a complex-network evolutionary game model. While that line of work is not about technical proposal automation, it is useful as contextual evidence on industrial adoption conditions and inter-firm diffusion dynamics.

A third limitation is maturity. Many reported systems remain prototypes or pilots, and applied comparative studies are scarce, particularly in real industrial settings with heterogeneous data sources and organizational constraints [12]. Even when evaluations exist, the field lacks a standardized evaluation protocol for agentic RAG, which complicates cross study comparisons [13,14]. Recent surveys and frameworks also raise questions about when and how large language models should be used as evaluators for RAG pipelines, given sensitivity to prompts, judge models, and dataset design [15].

2.2. Foundations: Retrieval Augmented Generation and Agent Architectures

RAG systems combine a generative model with retrieval from external knowledge sources, aiming to ground generated answers in documents, databases, and other organizational repositories. In industrial settings, the motivation is often pragmatic: technical knowledge is distributed across vendor catalogs, standards, internal procedures, drawings, and pricing databases, and it evolves over time. Comparative and architectural discussions emphasize that RAG design choices affect robustness when systems are applied across domains and heterogeneous sources [16,17], and systematic reviews highlight persistent issues such as hallucination risk, evaluation ambiguity, and sensitivity to retriever quality [4,5].

Industrial engineering tasks also impose constraints that differ from many general purpose question answering benchmarks. Outputs frequently need numerical correctness, consistent units, and traceable sourcing. Inputs include domain specific terminology and partially structured artifacts (tables, specifications, and drawings). These constraints motivate agentic and multi-agent RAG architectures, where specialized components handle distinct responsibilities such as query reformulation, retrieval refinement, answer validation, and evidence alignment [18]. In a related direction, multi-agent collaboration has been proposed as a way to improve generation accuracy in technical and multilingual contexts [19], and multi-agent scientific question answering provides another example of decomposing retrieval and synthesis into multiple coordinated roles [20].

Agentic designs also extend beyond text-only retrieval. Hierarchical multi-agent multimodal RAG aims to coordinate retrieval across modalities and levels of abstraction, which is relevant when engineering knowledge appears in mixed formats such as tables, plots, and diagrams [21]. Another line of work introduces human participation directly in the retrieval stage, positioning domain experts as active elements of the retrieval loop rather than passive consumers of generated answers [22]. Across these approaches, orchestration is a central concept: the system must manage the interaction among retrievers, generators, and external tools or data sources in a way that remains stable under changing data and user requirements [17].

2.3. Retrieval and Representation Strategies for Technical Domains

A recurring design tension in industrial RAG is the tradeoff between semantic coverage and traceability. Dense retrieval improves coverage of paraphrases and domain variants, while sparse retrieval improves interpretability and auditing because matches can be explained via lexical evidence. Hybrid retrievers combine these properties and are often presented as a practical default for technical domains where both recall and accountability matter [16,23]. Evaluation oriented work also reflects this tension: indexing choices and distance metrics are treated as levers that change retrieval behavior and, by extension, downstream generation quality [14]. Related evaluation efforts propose automated comparative frameworks for variants such as RAG fusion, which can help operational teams test retrieval combinations under a single scoring and ranking approach [13].

Knowledge organization through knowledge graphs is another consistent theme. Knowledge graphs structure domain specific entities and relations, which can reduce ambiguity in technical terminology and support more targeted retrieval over heterogeneous sources. This strategy has been discussed in engineering oriented RAG contexts [7], in settings focused on power standards and electrical knowledge [9], and in broader reviews of knowledge graph-based reasoning in power systems [10]. Work on enterprise graph RAG systems for question answering also reflects the practical motivation for graph-based retrieval in organizations, sometimes referenced under abbreviations such as SAGE-QA in that literature [24]. In parallel, hybrid strategies integrate symbolic elements with semantic retrieval to emphasize deterministic, explainable behavior, as illustrated by a symmetric knowledge graph and database hybrid RAG approach in a welding process question answering context [25]. Structured retrieval approaches also appear in multi entity question answering over heterogeneous sources, where retrieval must return evidence that can be aligned to multiple entities and attributes rather than a single narrative answer [26].

Representation learning for retrieval is another key factor because RAG performance depends on embeddings and similarity measures. Work that traces the effect of embedding quality from retrieval to final response reinforces that retrieval errors can propagate into confident but incorrect outputs [27]. Comparative studies of embedding models for RAG further highlight that embedding choice is not a neutral implementation detail, especially when newer large language models and embedding families are compared under semantic similarity objectives [28]. For engineering retrieval specifically, domain adaptation of document embeddings has been explored as a way to better align similarity with technical intent rather than general language similarity [29].

Pruning and source selection address scalability and noise. Multi source knowledge pruning has been studied as both a benchmarking problem and an empirical strategy to reduce irrelevant retrieval when knowledge bases become large and redundant [30]. Related ideas appear in generation tasks that use hierarchical pruning strategies to control which information is retained for downstream instruction generation, illustrating a general technique for constraining context and improving reuse of relevant documentation [31].

Finally, many industrial artifacts are not purely textual, so multimodal retrieval is increasingly relevant. Agentic multimodal RAG has been used to retrieve and interpret curves and images from PDFs and web sources, a capability that aligns with engineering workflows where plots, diagrams, and scanned specifications carry critical information [32]. Hierarchical multimodal RAG architectures extend this direction by explicitly coordinating retrieval across modalities and levels, which can be important for tasks that mix requirements text with drawings and tabular catalogs [21].

2.4. Transparency, Explainability, and Trust

Transparency and trust are central to industrial adoption because engineering outputs are reviewed, audited, and often tied to safety, compliance, and commercial risk. Conceptual work on transparent machine reasoning frames transparency as a practical requirement when AI systems influence decisions rather than only producing text [33]. In manufacturing related contexts, ontology-based explainable AI surveys emphasize that structured domain knowledge can support explanations that are consistent with how engineers justify decisions [34]. In the specific context of agentic RAG, systematic reviews of explainability focus on how explanations can be attached to different pipeline components (retrieval, planning, and generation) rather than treating the model as a single black box [6].

Several approaches explicitly combine language models with structured representations and logical reasoning to support verifiable outputs. For example, TranspNet proposes combining language models, ontologies, and logical reasoning with the objective of producing transparent and trustworthy behavior [35]. Related work proposes RAG-based interpretability mechanisms that aim to generate explanations that are usable by non-technical stakeholders, which is relevant when proposal outputs must be reviewed by commercial, operational, and engineering teams [36]. Industrial chatbot work also emphasizes interactive settings where users expect traceable answers that can be reconciled with organizational knowledge and standards [37].

Auditability and traceability connect directly to retrieval design. Symmetric hybrid strategies emphasize explicit evidence and deterministic retrieval behavior, supporting inspection of how a generated response is grounded in retrieved knowledge [25]. Multi-agent scientific question answering also highlights traceability as a practical requirement when systems are used for knowledge intensive tasks [20]. Complementary work addresses dataset and evaluation traceability through context identifiers and graph-based visualization, enabling reproducibility and clearer attribution between retrieved contexts and generated outputs [38]. At the evaluation layer, faithfulness and evidence alignment are increasingly assessed using LLM-based judging frameworks, which raises methodological questions about reliability and consistency of the judges themselves [15,39].

2.5. Evaluation Practices and General Open Challenges

Evaluation remains one of the strongest constraints on progress and comparability in RAG research. Systematic reviews emphasize that techniques evolve faster than the evaluation standards used to validate them [4,5]. Comparative evaluation studies across RAG architectures similarly show that design, implementation, and assessment choices can materially change conclusions, especially when systems are applied across domains [16]. In response, several works propose more structured evaluation methods: Elo-based automated ranking frameworks for comparing RAG fusion variants [13], evaluation of advanced RAG techniques through explicit indexing and distance metric analysis [14], and dataset-level traceability and visualization to support interpretability and reproducibility in evaluation [38]. At the same time, surveys focusing on LLM-based evaluation note that using LLMs as judges introduces additional uncertainty and potential bias, which must be managed explicitly if such judging is used for system selection or regression testing [15]. Related work evaluates faithfulness in agentic RAG using LLM judging in applied public sector settings, reinforcing both the practical relevance and the methodological sensitivity of this evaluation approach [39].

Two gaps are especially relevant for industrial deployment. The first is the need for holistic evaluation that goes beyond answer quality to include cost, latency, safety, and provenance, because these factors determine whether an approach can be sustained in production [4,6,12,40]. The second is scalability and operational robustness. While prototype systems demonstrate feasibility, strategies for reliable real time deployment, maintenance under evolving data sources, and principled human involvement remain underexplored [13,14,22]. Evidence from industry interviews reinforces that requirements include not only technical performance, but also integration constraints, accountability, and workable evaluation practices inside organizations [12].

2.6. Focus to This Paper: Implications for Automated Technical Proposals in Electrical Rooms

Within the scope of this paper, the literature indicates that many AI components needed for proposal automation are available, including agentic and multi-agent RAG pipelines, hybrid retrieval, multimodal extraction, and knowledge-graph-assisted retrieval. However, these components are typically presented as modular improvements in retrieval and generation, and rarely incorporate the representation of engineering systems and the mathematical decision layers that, in our experience, are required to make technical proposals reliable, comparable and operationally useful. The main challenges that emerge from this literature are the absence of explicit engineering-system representations, the limited integration of decision layers with retrieval pipelines, and the scarcity of evaluation protocols aligned with industrial traceability and deployment constraints.

Engineering-oriented RAG supported by knowledge graphs aims to improve retrieval relevance and reasoning over domain concepts, enabling tasks that resemble equipment selection, sizing, and layout reasoning [7,9,10]. Interactive industrial knowledge management systems based on RAG show how engineers and technicians can retrieve and validate technical information within workflow settings, rather than as isolated one-shot question answering [8]. Symmetric hybrid approaches illustrate how the combination of structured knowledge with retrieval can improve auditability through more explicit evidence and more deterministic behavior [25]. Multimodal and hierarchical multi-agent RAG methods demonstrate that extracting and using information from PDFs, images, and tables is feasible, which is directly relevant when proposals depend on vendor documentation, diagrams, and tabular catalogs [21,32]. Pruning and source selection strategies further indicate that controlling retrieval noise and context growth is necessary as knowledge bases scale [30,31].

At the same time, the evidence base helps explain why end-to-end automation for electrical room proposals remains difficult. Agentic RAG evaluation practices are not standardized, applied comparative studies in industrial settings are still limited, and deployment requirements such as traceability and numerical correctness are not addressed uniformly across reported systems [12,13,14]. These limitations are relevant, and broader adoption-oriented studies in industrial settings are also informative for context [11], but they are not the primary gap that motivates this paper. Accordingly, the present work does not attempt to define a universal benchmarking protocol for proposal-automation systems; its focus is the formulation of the problem and the integration of retrieval, system representation, and decision layers in an operational industrial workflow.

The purpose of this paper is to report on an industrial deployment focused on electrical room design and technical proposals and, more importantly, to show how the automation problem can be formulated as an engineering system with explicit mathematical structure. We use a functional and physical graph representation of the electrical room to organize the retrieval and embeddings, we compute a baseline proposal through cost-based optimization, and we generate and rank technically feasible alternatives using TOPSIS. This integrated perspective connects retrieval and generation to system modeling and decision-making, providing a disciplined and scalable route from requirements and heterogeneous sources to auditable proposals that support both engineering rigor and commercial selection.

Classical product configurators and constraint satisfaction systems have long addressed structured equipment configuration problems. The distinctive element in our setting is that structured configuration is not driven by a fully specified form-based input, but by requirements extracted from heterogeneous documents through retrieval and language models. The mathematical layer therefore operates downstream of flexible requirement interpretation rather than as a stand-alone configurator.

3. Systems Modeling and Graph Representation

Like any electrical network, an electrical room can be described as a system whose functional goals and physical structure naturally form a graph. Engineers often rely on graph representations because they support clear communication, enable behavior prediction methods, and facilitate systematic design. In our context, the same idea becomes a prerequisite for automation with artificial intelligence: without an explicit system description, it is difficult to build a solution that can be maintained, audited, and scaled beyond the initial quoting stage.

This system perspective matters for two reasons. First, an electrical room proposal is not only a text artifact; it is a technically constrained configuration of equipment and interfaces that must remain consistent across single-line diagrams, layout, the bill of materials, and supporting documentation. Second, within an industrial company, the proposal workflow must coexist with evolving equipment databases, project histories, and enterprise tools. In practice, the system representation is what makes it feasible to update catalogs, reuse technical knowledge across projects, and later connect with construction and operations information systems (for example BIM, digital twins, and digital invoicing). For these reasons, before introducing the optimization and ranking layers, we first define the electrical room as a system and formalize its graph representation.

3.1. Electrical Room as a System

Figure 1 provides a preliminary black-box view of an electrical room from a systems standpoint: an incoming power feed is transformed and conditioned to supply downstream industrial loads. However, the internal structure of the electrical room remains implicit in that figure. Here we make the internal decomposition explicit because it is the basis for the data organization and the automation logic used later in the paper.

An electrical room, understood as a system, receives an incoming power feed defined by the site interface. In many projects, the incoming interface is determined by a client-side transformer and upstream facilities, which become the physical boundary conditions for the electrical room that must be designed and quoted. The electrical room can then deliver multiple outputs (interfaces) depending on the client requirements. The most common outputs include:

• Lighting and auxiliary power distribution: supply and protect lighting and auxiliary services through distribution boards and feeders aligned with plant standards.
• Power distribution for process loads: provide controlled and protected feeders for downstream panels and equipment requiring low or medium voltage power.
• Variable-speed or variable-frequency supply: enable variable operating conditions for loads that require frequency conversion, typically through variable frequency drives.
• Motor control: provide motor starting, protection, and operational control functions, commonly centralized through motor control centers.
• Reactive power compensation: support power factor control through reactive power compensation equipment, typically capacitor banks and associated switching and protection.

These outputs are defined by the client through requirements documents (RFPs) and project constraints. The role of the provider is to configure the internal solution and deliver the full proposal package, including single-line diagrams, layout, an equipment list with pricing, and supporting technical documentation. To deliver the requested outputs, engineers interconnect a set of elements (equipment blocks) through well-defined electrical interfaces and physical connections (for example cables and busbars). Typical blocks include the following:

• Transformers: perform voltage level adaptation when transformation is within the scope of the electrical room solution.
• Variable frequency drives (VFDs): provide frequency conversion to support variable-speed operation and controlled motor supply.
• Capacitor banks: provide reactive power compensation to improve power factor and reduce reactive demand from the upstream network.
• Switchgear: provide switching, protection, and isolation functions at the relevant voltage level, including coordination and safety functions.
• Motor control centers (MCCs): integrate motor feeders, protection devices, and control logic for groups of motors and related loads.
• Cables, busbars, and connectors: implement the physical and electrical interconnections that realize the topology of the solution.
• Outgoing distribution boards: provide organized feeder distribution to downstream circuits and loads, typically aligned with standard panel structures.
• HVAC and thermal management: maintain acceptable operating temperatures and environmental conditions for the installed equipment.
• Civil and structural enclosure: provide the physical infrastructure, interfaces, and constraints (space, routing, access) that shape feasible layouts.

Each block is itself a subsystem with inputs, outputs, and interface constraints (for example voltage level, current rating, protection requirements, connector types, and physical routing). This structure motivates an explicit graph description: the electrical room is not a collection of documents, but a connected system of functional requirements, equipment blocks, and interfaces. In our implementation, we use a notation inspired by SysML v2 ideas (functional decomposition, interfaces, and structure), but we extend it to reflect the prescriptive nature of the task: the goal is not only to retrieve information, but to generate a specific, technically viable proposal configuration with explicit design choices.

3.2. Electrical Room Representation as a Graph

• Definition 1—Requested output set:

For a given quoting instance, $\Omega$ denotes the set of requested outputs to be delivered by the electrical room.

• Definition 2—Function sequence:

For each $o\in \Omega$, the ordered sequence ${\left\{f_i^o\right\}}_{i=1}^{n_o}$ denotes the required functions that must be realized so that output o is technically delivered.

• Definition 3—Candidate block set:

$\Phi$ denotes the universe of admissible electrical-room functions, and B denotes the set of candidate equipment blocks considered for the instance after initial vendor and interface screening.

Representative scale: In representative industrial quoting cases in our operating context, instances are of the same order as the scale example used later in Section 4: around 15 requested outputs, about three function stages per output on average, and on the order of a few hundred candidate blocks after initial filtering. Exact project-level counts vary by client scope and are not disclosed for confidentiality reasons.

We formalize the client requirements as a set of requested outputs $o\in \Omega$. Not every project requires every possible output; however, the set $\Omega$ must cover the space of outputs that an electrical room may need to deliver in the company context. In this work, the outputs $o\in \Omega$ include the following:

• Supply lighting: provide power, protection, and distribution for lighting circuits and associated panels.
• Supply power (general services and process loads): provide protected feeders and distribution for loads requiring electrical power beyond lighting.
• Control motor speed: support variable-speed operation through controlled supply, typically implemented with frequency conversion.
• Control motor start and stop: implement switching, protection, and control functions for motor operation.
• Provide reactive power compensation: enable power factor control through reactive compensation equipment and related switching/protection.
• Provide variable-frequency output: supply loads that require frequency adjustment as part of the delivered electrical service.

Each output $o\in \Omega$ has technical attributes (for example connection voltage level, connector type, nominal and maximum power). In practice, not all attributes are fully specified in the RFP. A core objective of the automated pipeline is therefore to store these attributes in a structured way and to complete missing values through consistent engineering choices, so that the final proposal is complete and technically viable.

To deliver an output $o\in \Omega$, the electrical room must realize an ordered sequence of functions ${\left\{f_i^o\right\}}_{i=1}^{n_o}$, where each $f_i^o\in \Phi$ and $\Phi$ denotes the universe of functions available in the electrical room design space. In other words, the output is not produced directly; it is produced by traversing a sequence of functions that transform, protect, distribute, control, or condition the incoming power so that it meets the output specification. Each function can be realized by one or more equipment blocks $b\in B$. These blocks are the practical nodes of the graph. In the initial implementation, B includes core equipment classes such as $\{\mathtt{transformer},\mathtt{MCC},\mathtt{switchgear},\mathtt{VFD},\mathtt{capacitor\; bank}\}$, each with stored attributes that define its interfaces, operating limits, and commercial parameters (including brand, model, and price).

Most blocks are specialized and primarily implement a single function, but some blocks can cover multiple functions. We capture this relationship with a binary matrix $\Gamma \in {\{0,1\}}^{|\Phi |\times \left|B\right|}$, where ${\gamma }_{fb}=1$ if function f can be covered by block b, and ${\gamma }_{fb}=0$ otherwise. Similarly, we define $A\in {\{0,1\}}^{|\Phi |\times |\Omega |}$, where ${\alpha }_{fo}=1$ if function f participates in delivering output o, and ${\alpha }_{fo}=0$ otherwise.

This representation turns the electrical room from a purely physical concept into an explicit mathematical structure: outputs $o\in \Omega$ induce ordered sequences of functions $f\in \Phi$, and those functions are instantiated by blocks $b\in B$ that are connected through physical and functional interfaces. The resulting graph representation imposes technical coherence and provides the organizing structure for data and retrieval: it defines what must be retrieved (attributes, constraints, and compatible equipment choices) and where that information belongs within the engineered system. In Figure 4 we show an example of the graph representation of a simplified E-house.

Finally, beyond the structural relationships among outputs, functions, and blocks, the proposal workflow depends on attributes that determine whether a configuration is technically feasible and commercially usable. We therefore complement the graph structure with the attribute descriptions of the system objects, which enable consistent assembly of an electrical room solution and support traceability from requirements to equipment selection. These attributes are also the basis for the upstream compatibility filtering described later in Section 4. Figure 5 summarizes this object and attribute view.

4. Cost-Based Optimization Model

Up to this point, we have defined the functional and physical graph representation of an electrical room, where client requirements are formalized as requested outputs $o\in \Omega$. Each output o is realized by an ordered sequence of functions ${\left\{f_i^o\right\}}_{i=1}^{n_o}$ with $f_i^o\in \Phi$, and each function can be implemented by one or more candidate equipment blocks $b\in B$. The binary matrix $\Gamma$ with entries ${\gamma }_{fb}$ indicates whether block b can cover function f. The matrix A with entries ${\alpha }_{fo}$ is retained as a bookkeeping object that summarizes which functions appear in each output; however, the optimization model below operates directly on the ordered sequences $\left\{f_i^o\right\}$ because the proposal must cover all required functions for each requested output.

To translate the representation into a concrete baseline proposal, we embed the following prescriptive optimization layer as an internal tool within the MA-RAG pipeline. The model selects a subset of blocks and assigns every required function in every output sequence to a selected feasible block, while minimizing internal cost and enforcing block sizing limits.

• Definition 4—Baseline proposal

A baseline proposal is a technically feasible configuration that covers all required function instances and minimizes total internal cost under the present formulation.

4.1. Parameters

For each block $b\in B$, let $c_b\ge 0$ denote its internal cost and let ${\mathrm{Cap}}_b>0$ denote its available capacity. (The capacity unit is function-/block-dependent (e.g., kVA, kA, kvar) and must be consistent with the sizing requirement used for the functions assigned to block b. In the implementation, this consistency is enforced when constructing the feasible set B and the mapping matrix $\Gamma$. In the illustrative instance in Section 6, all demands and capacities are expressed in kVA). For each requested output $o\in \Omega$ and each position $i=1,\dots ,n_o$ in its ordered sequence, let $d_i^o\ge 0$ denote the maximum design sizing requirement associated with the function $f_i^o$. (Equivalently, $d_i^o$ can be understood as $d_{f_i^o}^o$ under the notation $d_f^o$ (design requirement of function f for output o)). In addition, we define an exogenous design loading factor ${\lambda }_o\in (0,1]$, provided by the client when value-engineering alternatives are desired. The effective sizing requirement used in the optimization is ${\lambda }_o{d}_i^o$. In the conservative baseline configuration, we set ${\lambda }_o=1$ for all $o\in \Omega$, which corresponds to sizing at the maximum requested demand.

4.2. Decision Variables

$$x_b=\left\{\begin{array}{cc}1,\hfill & \mathrm{if}\mathrm{block}b\mathrm{is}\mathrm{selected},\hfill \\ 0,\hfill & \mathrm{otherwise},\hfill \end{array}\right.$$

(1)

$$z_{bi}^o=\left\{\begin{array}{cc}1,\hfill & \mathrm{if}\mathrm{the}i\mathrm{th}\mathrm{function}{f}_i^o\mathrm{of}\mathrm{output}o\mathrm{is}\mathrm{assigned}\mathrm{to}\mathrm{block}b,\hfill \\ 0,\hfill & \mathrm{otherwise}.\hfill \end{array}\right.$$

(2)

4.3. Model

$${\displaystyle \begin{array}{ccc}\hfill & \underset{x,z}{min}\hfill & \sum _{b\in B}{c}_b{x}_b\hfill \end{array}}$$

(3)

$$\begin{array}{ccc}\mathrm{s}.\mathrm{t}.\hspace{1em}\hfill & \sum _{b\in B}{z}_{bi}^o=1\hfill & \hspace{1em}\hspace{1em}\hfill \forall o\in \Omega ,\forall i=1,\dots ,n_o\end{array}$$

(4)

$$\begin{array}{ccc}\hfill & z_{bi}^o\le {\gamma }_{f_i^{o}b}{x}_b\hfill & \hspace{1em}\hspace{1em}\hspace{1em}\hfill \forall b\in B,\forall o\in \Omega ,\forall i=1,\dots ,n_o\end{array}$$

(5)

$$\begin{array}{ccc}\hfill & \sum _{o\in \Omega }\sum _{i=1}^{n_o}{\lambda }_o{d}_i^o{z}_{bi}^o\le {\mathrm{Cap}}_b{x}_b\hspace{1em}\hspace{1em}\hspace{1em}\hfill & \hspace{1em}\hspace{1em}\hfill \forall b\in B\end{array}$$

(6)

$$\begin{array}{ccc}\hfill & x_b\in \{0,1\},z_{bi}^o\in \{0,1\}\hspace{1em}\hspace{1em}\hfill & \hspace{1em}\hspace{1em}\hfill \forall b\in B,\forall o\in \Omega ,\forall i=1,\dots ,n_o.\end{array}$$

(7)

The objective function (3) minimizes the total internal cost of the selected blocks. Constraint (4) enforces full functional coverage by requiring that every function in the ordered sequence of each requested output is assigned to exactly one block. Constraint (5) couples assignment and selection while enforcing technical feasibility: a function instance can be assigned to a block only if (i) the block is selected and (ii) the block can cover the corresponding function according to $\Gamma$. Constraint (6) enforces sizing limits so that blocks may be shared across multiple outputs only when the aggregate assigned design requirements remain within their capacities.

4.4. Implementation and Scalability Note

Detailed interface and connector compatibility rules are enforced upstream when constructing the feasible block set B and the mapping matrix $\Gamma$ from vendor data and engineering rules, using the object attributes summarized in Figure 5. The logic is sequential rather than circular: requested outputs are first decomposed into ordered function stages, each function stage carries required interface attributes, and candidate blocks are then queried only from the limited vendor set that satisfies those attributes. Representative filtering attributes include voltage level, connector or coupling standard, admissible input/output power, and switching configuration. Only compatible function–block pairs are retained in $\Gamma$. As a result, the optimization layer receives a sparse feasible set that focuses on functional coverage and sizing, while detailed incompatibilities are resolved before the optimization step.

From a computational standpoint, let $F={\sum }_{o\in \Omega }{n}_o$ denote the total number of required function instances. In dense form, the formulation contains $\left|B\right|+\left|B\right|F$ binary variables and $F+\left|B\right|F+\left|B\right|$ constraints, so the model size grows linearly in the number of candidate blocks and required function instances. Moreover, the activation constraints use tight physical coefficients rather than loose artificial large constants. For a representative case with 15 requested outputs, an average of three functions per output ($F=45$), and $\left|B\right|=200$ candidate blocks, the dense form has 9200 binary variables and 9245 constraints. This count is conservative because the practical instance is much sparser. If $K_i^o=\{b\in B:{\gamma }_{f_i^{o}b}=1\}$ denotes the compatible candidate set for function $f_i^o$, then the number of admissible function–block pairings is ${\sum }_{o\in \Omega }{\sum }_{i=1}^{n_o}\left|K_i^o\right|$, not $\left|B\right|F$. In typical quoting settings, each function instance is compatible with only a small vendor- and size-filtered subset of blocks. For example, with at most three approved vendor families and at most four modular size options per family for a given function, $|K_i^o|\le 12$, so the number of admissible pairings is at most $12F$ (540 when $F=45$), rather than 9000 in the dense count. In addition, requested outputs are usually realized through ordered, nearly linear function chains rather than dense meshed interconnections, and genuinely multi-function blocks are uncommon. The main source of combinatorial coupling is therefore shared capacity across outputs, not arbitrary network topology. The general problem remains combinatorial, but these structural properties make practical instances substantially more tractable than a worst-case enumeration would suggest.

4.5. Reliability, Redundancy, and Safety Extensions

The formulation above is intentionally a baseline cost-oriented coverage model for the quoting stage. In a fuller engineering model, reliability and redundancy requirements can be added on top of the same output–function–block structure. For critical outputs or function stages, N − 1 contingency requirements can be represented through reserve-capacity constraints that require the surviving selected blocks in a designated redundancy group to remain sufficient after the loss of any one block, or through duplicate-coverage constraints that force at least two independent compatible blocks for the critical function. More generally, primary/standby architectures can be modeled by separating normal and backup assignments when the project scope requires explicit backup paths. Protection coordination is more naturally incorporated as a combination of upstream feasibility filtering and pairwise compatibility rules between consecutive blocks, using attributes such as voltage level, interrupting rating, relay family, selectivity limits, and short-circuit withstand. Under that extension, the present optimization layer remains the baseline economic selector, while reliability and safety requirements are incorporated either as additional optimization constraints or as engineering admissibility rules used to construct the feasible set. A full time-current coordination study remains part of detailed engineering and is outside the scope of the present quoting-layer model.

5. Multi-Criteria Ranking of Alternative Solutions Using Fuzzy DEMATEL and TOPSIS

As the project progressed, we observed that the minimal cost solution, while useful as a baseline, is not always the most appropriate alternative to propose to a client. In practice, the final proposal must reflect additional constraints and preferences that are often only partially explicit early in the quoting stage. The most common reasons include the following:

• Compatibility: technical compatibility with the installed base, site standards, commissioning practices, and integration constraints.
• Internal exclusivity agreements: internal commitments to specific vendors or product lines in certain contexts.
• Client exclusivity agreements: vendor restrictions, approved vendor lists, or contractual clauses imposed by the client.
• Client preferences and exclusions: explicit preferences for specific brands or equipment families, and exclusions of others.

In our process, these aspects are incorporated as decision indicators evaluated after generating the set of technically feasible configurations. They are not imposed as hard constraints from the beginning because they can be project-dependent, incomplete at early stages, or subject to negotiation. Keeping them as indicators allows engineers to compare the feasible set first, and then apply the project-specific commercial rules and exclusions consistently.

The constraints of the cost model in Section 4 provide a structured way to generate technically feasible alternatives in terms of equipment connectivity and functional coverage, that is, consistency of the $(f,b,o)$ association. Once these feasible alternatives are available, selecting the most appropriate proposal becomes a multi-criteria decision problem where cost is only one dimension.

A methodological option considered initially was a multi-objective optimization model. While viable, that approach requires explicit numerical modeling of preferences and introduces additional complexity in the interpretation of tradeoffs. Instead, we adopted a simpler and more transparent procedure that matches engineering practice in the company: fuzzy DEMATEL is used to compute criterion weights based on expert judgment, and TOPSIS is then used to rank the feasible alternatives using those weights. DEMATEL and its fuzzy extension are established tools for modeling influence relationships among criteria and deriving a weight vector from expert assessments [41,42]. TOPSIS is an established method for ranking alternatives by relative closeness to an ideal solution [43]. Accordingly, the novelty claim of this paper is not based on fuzzy DEMATEL or TOPSIS in isolation, but on their integration downstream of the graph-structured retrieval and optimization layers within a document-grounded industrial proposal workflow. Similar fuzzy multi-criteria procedures are common in applied selection and ranking problems [44,45].

Figure 6 provides a schematic overview of the linked procedure used in our system.

5.1. Fuzzy DEMATEL for Criterion Weighting

Let n be the number of evaluation criteria. The objective of this stage is to compute normalized criterion weights $W_i$ that reflect expert judgments while accounting for mutual influence among criteria.

The DEMATEL method models cause and effect relationships among criteria through a directed influence structure. The fuzzy extension improves robustness when experts express their judgments linguistically rather than numerically [42].

Description 1. 

• D1. Expert elicitation: In operational use, criterion weighting is supported by a simple expert-preference elicitation administered to a committee of p specialist engineers. Each engineer provides Likert-style linguistic judgments on the pairwise influence among the n criteria using the five-level scale in

  Table 1. Linguistic scale and corresponding triangular fuzzy numbers.

  Linguistic Term	Fuzzy Value $(\mathit{\lambda },\mathit{m},\mathit{u})$
  High (H)	$(0.5,0.75,1)$
  Medium high (MH)	$(0.25,0.5,0.75)$
  Low (L)	$(0,0.25,0.5)$
  Medium low (ML)	$(0,0,0.25)$
  None (N)	$(0,0,0)$

  . These judgments are used only to compute criterion weights for the downstream TOPSIS stage; they do not modify the upstream cost-minimization model.
• D2. Linguistic scale: Each linguistic assessment is mapped to a triangular fuzzy number $(\lambda ,m,u)$ representing the lower, modal, and upper values of influence.
• D3. Direct relation matrices: Each expert k provides a fuzzy direct relation matrix $Z^k$, where $Z_{ij}^{\left(k\right)}$ represents the influence of criterion i on criterion j:

  $$Z_{ij}^{\left(k\right)}=({\lambda }_{ij}^{\left(k\right)},m_{ij}^{\left(k\right)},u_{ij}^{\left(k\right)}).$$

  (8)
• D4. Normalization: The fuzzy matrices are normalized using a scaling factor ${\beta }^k$ to obtain:

  $$X^k={\displaystyle \frac{1}{{\beta }^k}}{Z}^k.$$

  (9)
  The purpose of normalization is to ensure the influence structure is properly scaled so that the total relation matrix is well defined.
• D5. Aggregation across experts:  The normalized matrices are aggregated to obtain a group matrix X; for example, by averaging across experts:

  $$X={\displaystyle \frac{1}{p}}\sum _{k=1}^p{X}^k.$$

  (10)
• D6. Total relation matrix:  The total relation matrix T captures both direct and indirect effects among criteria:

  $$T=X{(I-X)}^{-1}.$$

  (11)
  This expression summarizes the accumulated influence along all paths in the directed criterion influence structure.
• D7. Defuzzification:  Each element of T is converted into a crisp score $F_{ij}$ to enable weight computation:

  $$F_{ij}={\displaystyle \frac{{\lambda }_{ij}^{″}+m_{ij}^{″}+u_{ij}^{″}}{3}}.$$

  (12)
• D8. Weight calculation:  Let $D_i={\sum }_{j=1}^n{F}_{ij}$ be the sum of row i and $R_i={\sum }_{j=1}^n{F}_{ji}$ be the sum of column i. Here, $D_i$ represents the total influence dispatched by criterion i, and $R_i$ represents the total influence received by criterion i. A raw importance score is computed as follows:

  $$w_i=\sqrt{D_i^2+R_i^2}.$$

  (13)
  Finally, the normalized criterion weights are as follows:

  $$W_i={\displaystyle \frac{w_i}{{\sum }_{i=1}^n{w}_i}}.$$

  (14)

The output of this stage is the weight vector $W=(W_1,\dots ,W_n)$, which is then used by TOPSIS to rank the feasible electrical room alternatives.

5.2. TOPSIS for Ranking of Electrical Room Alternatives

TOPSIS ranks m technically feasible electrical room alternatives using n criteria [43]. Let $X_{ji}$ denote the value of criterion i for alternative j. Criteria may be of two types: benefit criteria where larger values are preferred, and cost criteria where smaller values are preferred. The method proceeds as follows:

Description 2. 

• T1. Normalized decision matrix:  Each criterion column is normalized:

  $${\overline{X}}_{ji}={\displaystyle \frac{X_{ji}}{\sqrt{{\sum }_{j=1}^m{X}_{ji}^2}}}.$$

  (15)
• T2. Weighted normalized matrix:  DEMATEL weights are applied:

  $$V_{ji}={\overline{X}}_{ji}{W}_i.$$

  (16)
• T3. Ideal best and ideal worst solutions:  For each criterion i, define the ideal best value $V_i^{+}$ and the ideal worst value $V_i^{-}$. If criterion i is a benefit criterion, then $V_i^{+}={max}_j{V}_{ji}$ and $V_i^{-}={min}_j{V}_{ji}$. If criterion i is a cost criterion, then $V_i^{+}={min}_j{V}_{ji}$ and $V_i^{-}={max}_j{V}_{ji}$.
• T4. Distances to the ideal solutions:  For each alternative j, compute the Euclidean distance to the ideal best and ideal worst:

  $$S_j^{+}=\sqrt{\sum _{i=1}^n{(V_{ji}-V_i^{+})}^2},S_j^{-}=\sqrt{\sum _{i=1}^n{(V_{ji}-V_i^{-})}^2}.$$

  (17)
• T5. Closeness coefficient and ranking:  The relative closeness of alternative j to the ideal solution is

  $$P_j={\displaystyle \frac{S_j^{-}}{S_j^{+}+S_j^{-}}}.$$

  (18)
  Alternatives are ranked in descending order of $P_j$. Higher values indicate alternatives that are closer to the ideal best and farther from the ideal worst.

The result is a ranked list of technically feasible electrical room proposals that supports commercial and engineering decision making. In our workflow, additional project-specific indicators such as exclusivity clauses or compatibility flags are then applied to interpret the ranking in the context of the specific client and project constraints.

6. Results

This section reports results for a small illustrative instance with two requested outputs. Consistent with the end-to-end workflow shown in Figure 2, the proposed method operates as a staged decision-support pipeline. The pipeline proceeds by (i) defining the requested outputs and function sequences from the RFP, (ii) constructing the feasible function–block graph, (iii) computing the minimal-cost baseline, (iv) generating additional technically feasible alternatives, (v) deriving criterion weights with fuzzy DEMATEL, and (vi) ranking the alternatives with TOPSIS. The case study below is presented in that same sequence. The case is an anonymized illustrative instance derived from the operational structure of past projects rather than a full disclosure of a single proprietary project dataset. Its purpose is to make the integrated logic of the representation, optimization, and ranking layers transparent, not to provide a large-scale industrial benchmark. The corresponding computational scalability discussion for larger instances is given in Section 4.

6.1. Minimal Cost Solution

We consider two requested outputs. The first output is motor control with a maximum design demand of 700 kVA. The second output is a lighting system feeding and switching with a maximum design demand of 150 kVA. Both outputs require the same upstream stages and then diverge at the last stage. The ordered function sequence for motor control is HV to MV transformation, MV to LV transformation, and motor control. The ordered function sequence for lighting is HV to MV transformation, MV to LV transformation, and lighting distribution. For this baseline, the design loading factors are set to ${\lambda }_o=1$ for both outputs, so the sizing requirements used by the optimization match the maximum requested demand.

This example is representative of the framework’s logic even though it is intentionally small. It contains the recurrent structural ingredients that appear in practical quoting instances shared upstream stages, divergence into distinct terminal outputs, block sharing under capacity constraints, and multiple feasible alternatives with visible trade-offs across cost, lead time, and prestige. In larger instances, additional loads usually replicate these same functional lines and primarily increase upstream block capacities or the number of terminal modules, rather than changing the underlying structure of the formulation.

The equipment library contains 13 candidate blocks distributed across four function types. Each block has an internal cost and a capacity in kVA. The optimization selects a subset of blocks and assigns every function instance in each output sequence to exactly one selected feasible block, while enforcing that the aggregated assigned load does not exceed the capacity of a selected block.

The minimal cost solution selects four blocks with a total internal cost of 124.5.

Table 2. Minimal cost solution. Selected blocks and capacity usage.

Function Stage	Selected Block	Cost	Capacity (kVA)	Assigned Load (kVA)	Utiliz. (%)	Lead Time	Prest.
HV to MV trans.	HV to MV Transf. 900	18.0	900	850	94.4	12	7
MV to LV trans.	MV to LV Transf. 900	7.0	900	850	94.4	12	7
Motor control	MCC 700	98.0	700	700	100.0	16	5
Lighting dist.	Lighting Panel 200	1.5	200	150	75.0	8	6
Total		124.5

reports the selected blocks and their capacity usage. The HV to MV transformer and the MV to LV transformer are shared by both outputs because both outputs require the same upstream functions. Each of these transformers has a capacity of 900 kVA and is assigned a total load of 850 kVA, which corresponds to 94.4 percent utilization. The motor control block is an MCC with capacity 700 kVA, assigned load 700 kVA, and therefore 100.0 percent utilization. The lighting panel has capacity 200 kVA, assigned load 150 kVA, and therefore 75.0 percent utilization.

The internal cost distribution is dominated by the MCC. In this instance, the MCC accounts for approximately 79 percent of the total internal cost, while the two transformers account for about 20 percent and the lighting panel for about 1 percent. Figure 7 shows this breakdown.

Table 3. Minimal cost solution. Assignment of output function instances to blocks.

Output	Pos.	Function Stage	Demand (kVA)	Assigned Block
Control motors	1	HV to MV transformation	700	HV to MV Transformer 900
	2	MV to LV transformation	700	MV to LV Transformer 900
	3	Motor control	700	MCC 700
Lighting system feeding and switching	1	HV to MV transformation	150	HV to MV Transformer 900
	2	MV to LV transformation	150	MV to LV Transformer 900
	3	Lighting distribution	150	Lighting Panel 200

reports the assignment of each function instance to the selected blocks. Output 1 and Output 2 share the same upstream blocks for the first two stages, and then use distinct terminal blocks to deliver the motor control and lighting distribution functions, respectively.

Finally, two additional indicators are computed for completeness and to support the ranking stage. Lead time is computed as the maximum lead time among the selected blocks, which is 16 weeks for the minimal cost solution. Prestige is computed as a cost-weighted average of the selected block prestige scores, yielding 5.414. These indicators are not used by the cost minimization objective and are stored for the multi-criteria ranking stage.

6.2. Multi-Criteria Ranking Using Fuzzy DEMATEL and TOPSIS

The minimal cost solution provides a deterministic baseline, but it does not represent a complete selection rule when additional commercial indicators matter. To illustrate the ranking stage, we generated multiple technically feasible alternatives by repeatedly solving the assignment and selection problem while excluding previously found block sets. In this instance, this procedure produced 36 feasible alternatives.

The framework is not restricted to three criteria. In the present illustrative instance, each alternative is evaluated using the three indicators that are currently structured and consistently available in the block data and that can be judged reliably at the quoting stage. Total cost is the sum of internal costs of the selected blocks and is a cost criterion. Lead time is computed as the maximum lead time among the selected blocks and is also a cost criterion. Prestige is computed as a cost-weighted average of the selected block prestige scores and is treated as a benefit criterion. In this paper, prestige is an anonymized aggregate proxy for supplier- and brand-related preference patterns used in proposal practice; brand-specific judgments are not disclosed for confidentiality reasons. Additional engineering criteria, such as reliability, efficiency, or safety compliance, can be incorporated once those attributes are encoded in a homogeneous machine-readable form and considered decision-relevant by domain experts. Across the 36 alternatives, total cost ranges from 124.5 to 163.2, lead time ranges from 16 to 22 weeks, and prestige ranges from 5.180 to 7.887.

To compute criterion weights, we apply fuzzy DEMATEL to a simple elicitation of engineering preferences over the three criteria. In operational use, this step is implemented through Likert-style linguistic judgments from specialist engineers on the pairwise influence among cost, lead time, and prestige. The numerical pattern used in this illustrative instance is a simplified and anonymized representation of preference tendencies observed in practice at PRECISION; it is therefore operationally grounded, but it is not reported here as a standalone formal survey dataset. In particular, raw brand-specific judgments and vendor-linked preferences are not disclosed because they may reflect commercially sensitive internal criteria. The resulting normalized weights are shown in

Table 4. Criterion weights computed by fuzzy DEMATEL for the illustrative instance.

Criterion	Weight
Cost	0.377
Lead time	0.296
Prestige	0.327

. Cost receives weight 0.377, lead time receives weight 0.296, and prestige receives weight 0.327.

TOPSIS is then applied to rank the 36 alternatives using these weights, with the standard convention that lower values are preferred for cost and lead time and higher values are preferred for prestige.

Table 5. TOPSIS ranking results for the illustrative instance. Boldface identifies the best-ranked alternative, the lowest cost, the lowest lead time, and the highest prestige.

Alt	Cost	Lead Time (Weeks)	Prestige	${\mathit{P}}_{\mathit{j}}$	Rank	Selected Blocks
17	134.2	18	6.301	0.560	1	HV to MV Transf. 900, MV to LV Transf. 1200, MCC 900, Lighting Panel 400
15	133.5	18	6.270	0.559	2	HV to MV Transf. 900, MV to LV Transf. 1200, MCC 900, Lighting Panel 200
14	132.2	18	6.222	0.558	3	HV to MV Transf. 900, MV to LV Transf. 900, MCC 900, Lighting Panel 400
13	131.5	18	6.190	0.556	4	HV to MV Transf. 900, MV to LV Transf. 900, MCC 900, Lighting Panel 200
6	127.2	16	5.547	0.534	5	HV to MV Transf. 900, MV to LV Transf. 1200, MCC 700, Lighting Panel 400
18	134.2	18	6.145	0.533	6	HV to MV Transf. 900, MV to LV Transf. 800, MV to LV Transf. 200, MCC 900, Lighting Panel 400
3	126.5	16	5.510	0.532	7	HV to MV Transf. 900, MV to LV Transf. 1200, MCC 700, Lighting Panel 200
16	133.5	18	6.112	0.532	8	HV to MV Transf. 900, MV to LV Transf. 800, MV to LV Transf. 200, MCC 900, Lighting Panel 200
2	125.2	16	5.452	0.530	9	HV to MV Transf. 900, MV to LV Transf. 900, MCC 700, Lighting Panel 400
1	124.5	16	5.414	0.528	10	HV to MV Transf. 900, MV to LV Transf. 900, MCC 700, Lighting Panel 200
30	159.2	22	7.887	0.510	16	HV to MV Transf. 900, MV to LV Transf. 1200, MCC 1400, Lighting Panel 400

reports the top 10 ranked alternatives and also reports the alternative with the highest prestige score.

The best ranked alternative is Alternative 17 with closeness coefficient 0.560. It selects an HV to MV transformer rated 900 kVA, an MV to LV transformer rated 1200 kVA, an MCC rated 900 kVA, and a lighting panel rated 400 kVA. This alternative has total cost of 134.2, lead time of 18 weeks, and prestige of 6.301. The minimal cost alternative is Alternative 1 with total cost 124.5 and lead time 16 weeks, but it ranks tenth under TOPSIS because its prestige score is lower at 5.414. The alternative with the highest prestige score is Alternative 30 with prestige 7.887, but it is not top ranked because it also has higher cost and longer lead time.

Under the baseline weights, Alternative 17 emerges as the best-ranked option because it offers the most balanced profile across the three criteria rather than the best value in any one of them taken separately. Alternative 1 is the boundary solution on cost and lead time, but its lower prestige prevents it from dominating under the present preference profile. Alternative 30 is the opposite boundary case: it maximizes prestige, but does so at substantially higher cost and longer lead time. The best-ranked result should therefore be interpreted as a compromise solution under the baseline weighting. If the decision-maker shifted toward a more cost- and time-oriented strategy, Alternative 1 would become more attractive; if the strategy became more prestige-oriented, Alternative 30 would become more attractive.

More generally, the TOPSIS ranking is not invariant to changes in criterion weights or normalization rules. By construction, the weights enter the weighted normalized matrix through Equation (16), and the normalization rule affects the scaled criterion values through Equation (15); either type of change can therefore modify the distances to the ideal solutions and potentially alter the ranking. In the present instance, the top-ranked alternatives are numerically close ($P_j=0.560$, 0.559, 0.558, and 0.556), so local reorderings among the top positions are plausible under alternative preference profiles or normalization choices. By contrast, Alternative 1 and Alternative 30 remain interpretable as cost/time-oriented and prestige-oriented boundary cases, respectively. Formal weight-sensitivity intervals, normalization-sensitivity studies, and full-range weight sensitivity analysis have been proposed in the TOPSIS literature and constitute a natural next step for this decision layer [46,47,48].

6.3. Overview of the Implemented Tool in the Company Workflow

This section has focused on the mathematical representation and decision layers that support proposal generation. To complement those results, we briefly summarize how the approach is used inside the company workflow through a working prototype that has been presented in three internal demos. The goal of this subsection is not to claim a full end-to-end industrial benchmark, but to show how the structured representation described in the paper connects to concrete user interactions and to traceable intermediate artifacts. No directly comparable end-to-end proposal-automation tool baseline is currently available in our setting. A narrow internal check on the extraction module, conducted on a small set of recent projects ($n=8$), suggested a reduction in manual consolidation time from several hours to less than 30 min per project, excluding final human validation; this observation should be read only as implementation feedback, not as a benchmark of the full proposal pipeline. In parallel, the broader workflow is currently being assessed retrospectively on previously completed projects that were successful in terms of execution, delivery, and client continuity. In those cases, historical proposals are being reconstructed and compared against the realized project baseline on practical indicators such as elapsed time from first client contact to proposal delivery, total equipment-list cost, load-capacity slack, compliance with requested usage-factor requirements, proposal completeness and coherence under expert review, and human correction burden. This protocol is specific to our operating context and remains under development, so we do not present it here as a completed statistical benchmark or as a universal evaluation standard for proposal-automation systems. Nor do we claim that the current ranking coincides with an external independent expert consensus, since such a study has not yet been completed. Accordingly, the evidence reported here should be read as operational integration evidence rather than as a comparative proof of superiority over alternative methods.

The prototype is organized around a project workspace where engineers upload and manage the documents that usually initiate a quotation. The workspace centralizes heterogeneous inputs, including technical requests, drawings, and supporting files, and it assigns each document to a small set of engineering categories used downstream. This step matters because most of the information required for an electrical room proposal is scattered across artifacts with different formats. By keeping the documents in a single project space and attaching a consistent label set, the tool establishes a simple but explicit data boundary for retrieval and for subsequent reasoning tasks.

Once documents are available in the workspace, the tool provides a document reader that extracts a structured equipment list from documents that contain tabular or semi tabular descriptions. Figure 8 shows an example based on a disposition plan. The left side displays the source document, while the right side reports the extracted items as a table with equipment identifier, quantity, description, and equipment type. The user can review the extracted list, correct individual fields if needed, and approve the result. This review step is intentional. It keeps the human engineer in control of the structured data that will later be used as input for proposal generation, and it preserves traceability from the structured list back to the original document.

The demos also include an internal mapping of the quotation process that contrasts the current manual workflow with a workflow supported by the prototype. The mapping suggests that document consolidation and equipment list preparation can be shifted from manual compilation to automated extraction, while still keeping a dedicated validation step before proposal generation. In the context of this paper, these demos should be read as implementation evidence that the modeling and decision layers can be embedded in day-to-day engineering work, rather than as a quantitative benchmark. The broader retrospective evaluation protocol described above is currently under development and is intended to complement these implementation observations with project-level comparisons against historical baselines.

The industrial context of this work is not external to the authorship. Three co-authors are engineers at PRECISION and are directly involved in the design and quotation of electrical rooms. One of them participated actively in the development of the prototype and is an end user of the tool in day-to-day proposal preparation. This dual academic–industrial collaboration shaped the modeling choices, the definition of functional abstractions, and the validation steps reported in this paper. The intention is not to claim superiority through authorship, but to clarify that the system was designed and evaluated within an operational engineering environment rather than as a purely laboratory prototype.

7. Conclusions and Future Work

This paper formulated the automation of technical proposals for industrial electrical rooms as an integrated decision workflow rather than as a stand-alone text-generation task. The proposed workflow combines a functional and physical graph representation of the electrical room, a mixed-integer optimization model that computes a minimal-cost technically feasible baseline, and a downstream ranking layer based on fuzzy DEMATEL and TOPSIS. The result is a document-grounded and auditable proposal process that supports both engineering consistency and commercial selection.

The contribution is an applied methodological integration supported by an illustrative industrial case and implementation evidence. The mathematical components themselves are established; the contribution lies in integrating them with explicit system representation and industrial workflow constraints so that heterogeneous requirements can be transformed into technically feasible and comparable proposal alternatives.

From a practical standpoint, three guidelines follow from the present results. First, retrieval for engineering proposals benefits from an explicit functional and physical graph representation rather than from a flat document taxonomy because this improves traceability and reduces cross-artifact inconsistency. Second, proposal automation should not rely on cost minimization alone: a baseline optimizer is useful for feasibility and internal consistency, but final commercial selection benefits from an explicit ranking layer that makes trade-offs visible. Third, the main operational gains come from integrating document handling, structured engineering data, and decision layers within one workflow, rather than from deploying isolated AI tools in a fragmented way.

This work also has important limitations. First, the case study is illustrative and implementation-oriented rather than a comparative benchmark, so the paper does not establish that the proposed pipeline is superior to alternative automation or decision methods. Second, the empirical grounding of the ranking layer is limited: the criterion weights are operationally informed and anonymized, but they are not reported as a standalone formal survey dataset, and no independent external expert study is yet available. Third, the optimization model is intentionally a deterministic baseline coverage formulation; broader generality would require richer engineering feasibility, more expressive objective functions, redundancy and protection constraints, and possible stochastic or robust extensions. Fourth, the multi-criteria decision layer is deliberately lightweight: its simplicity supports fast deployment and interpretable trade-offs at the quoting stage, but it does not exhaust richer multi-objective or probabilistic decision models. These limitations mean that the present results should be interpreted as evidence that the integrated workflow is workable and useful in practice, not as definitive proof that it is optimal or universally best.

Several research and development directions follow naturally. A first priority is to complete the retrospective evaluation protocol currently under development in the company, using previously completed successful projects to compare reconstructed proposals against historical baselines on elapsed time from first client contact to proposal delivery, total equipment-list cost, load-capacity slack, compliance with requested usage-factor requirements, proposal completeness and coherence under expert review, and human correction burden. This should be complemented by controlled comparisons against manual and semi-manual baselines and by component-wise comparisons (graph-structured retrieval vs. document-taxonomy retrieval, with and without optimization, and with and without multi-criteria ranking), using metrics that reflect industrial requirements such as numerical correctness, traceability of evidence, proposal coherence across artifacts, latency, and operational cost. Because the literature still lacks standardized evaluation protocols for agentic RAG in industrial settings, we do not present this company-specific protocol as a universal benchmark, but as a practical validation route for the present deployment. Second, the engineering constraint set should be enriched so that critical outputs can be modeled with explicit redundancy, N − 1 contingency-reserve requirements, and protection-coordination admissibility conditions while preserving the output-function-block representation used here. Third, client preferences and constraints should be incorporated more explicitly, either as structured inputs to the decision model or as constraints/indicators learned from historical projects (e.g., approved vendor lists, site standards, and negotiation-driven exclusions). Concrete near-term application areas include retrofit and expansion proposals for existing industrial plants, standardized quotation of recurrent electrical-room configurations, and early vendor-comparison support when approved-vendor lists materially restrict the feasible set. Fourth, the multi-criteria ranking stage can be strengthened by learning or calibrating TOPSIS weights from data (for example, from historical acceptance outcomes, engineering revision logs, or post-mortem assessments), by testing robustness with respect to alternative weight vectors and normalization rules, and by comparing the present ranking layer with broader sensitivity-analysis procedures, while preserving interpretability [46,47,48]. Related robustness-oriented fuzzy MCDM extensions in other application domains also point in this direction [49]. More broadly, these extensions aim to reinforce the paper’s main premise: scalable and auditable automation in engineering proposals depends on explicit problem formalization and integrated decision logic, and it can be extended naturally toward downstream detailed-engineering, digital-twin, E-BOM, and enterprise-planning integration.