Topics in AI systems: Part IV – Practical Applications and Challenges of GNN+LLM Fusion

In Part I of this series, we introduced the idea that Graph Neural Networks (GNNs) and Large Language Models (LLMs) are fundamentally different but complementary forms of AI. GNNs understand relationships and structure, while LLMs understand language, documentation, and engineering context. In Part II, we reviewed different types of GNNs and LLMs so developers and architects can select appropriate models for different Digital Industries use cases. In Part III, we moved from model selection to architecture and implementation patterns, showing that GNN+LLM fusion is not a single model, but a system architecture built from data sources, knowledge graphs, GNNs, retrieval, LLMs, orchestration, and applications. In this Part IV of the series, we focus on a practical question: When should developers use GNN+LLM fusion, and when might a simpler approach be more appropriate? Figure 1 illustrates some application areas and challenges of a GNN+LLM system and shows the potential impact. Here, we will discuss these challenges and opportunities, as well as economic justification, in the context of product-design change that is one of the most critical issues in complex engineered systems.

Figure 1: GNN+LLM fusion challenges, opportunities, and practical applications in Digital Industries.

I. When GNN+LLM Fusion Makes Sense

GNN+LLM fusion makes sense when the problem requires both structural reasoning and semantic understanding. For Design-Change Impact Analysis (DCIA), for instance, this usually means the system has many interdependencies, the relevant data is spread across multiple sources, and the answer must be explainable to engineers. Here are several use cases from digital industries where a GNN+LLM model could be effective.

Use Case 1: When the Design Has Many Interconnected Dependencies

Fusion is valuable when a design change can propagate across many layers of a system. For example, in an electric vehicle, a change to a battery cooling component may affect thermal performance, battery safety, control software, electrical power consumption, packaging constraints, manufacturing steps, service procedures, and verification tests.

A traditional search system may retrieve documents mentioning the component. That is useful, but incomplete. A GNN-based approach can analyze the connected structure of the system and identify downstream dependencies. An LLM can then explain those dependencies in natural language and summarize the evidence.

Use Case 2: When Impact Paths Matter

In engineering, it is often not enough to say that two items are related. Developers and engineers need to know how they are related. For example, component A connects to Subsystem B, which satisfies Requirement C, which is verified by Test D, which was last updated after Change Request E. This path matters because it provides traceability.

Direct graph queries are well suited to identify known relationships and explicit traceability paths. GNNs become useful when the model must learn from historical patterns and rank uncertain downstream impacts. It also is practical while it infers missing or weak relationships and prioritizes indirect dependencies that are not captured by the simple traversal rules; then, LLM models can convert those paths into an understandable engineering explanation.

For DCIA, this combination can support questions such as:

• Which requirements may be affected?
• Which tests should be rerun?
• Which simulations may no longer be valid?
• Which manufacturing processes may need review?
• Which suppliers or service teams should be notified?
• Which prior change requests are similar?

Use Case 3: When Relevant Data Is Both Structured and Unstructured

Industrial knowledge is often fragmented across multiple systems, formats, and lifecycle stages.  DCIA may require data from PLM systems, ALM systems, requirements repositories, CAD and ECAD metadata, simulation results, test reports, manufacturing plans, supplier documentation, service records, and change histories.  Some of this information is structured, some is semi-structured and perhaps buried in various documents and others may exist only as relationships among objects. GNNs are useful for the structured and relational layer; LLMs are useful for interpreting text, requirements, reports, and human-authored engineering knowledge. Fusion makes sense when both are required.

Use Case 4: When Traceability and Evidence Are Required

In Digital Industries, especially in regulated domains such as aerospace, automotive, medical devices, and energy, AI recommendations must be traceable. A useful DCIA system should show:

• Which objects were considered
• Which graph paths were followed
• Which documents were retrieved
• Which requirements, tests, or simulations were affected
• Which assumptions were made
• Which confidence level was assigned
• Which human reviewer accepted or rejected the recommendation

A pure LLM response may sound convincing but lack structural evidence. A pure GNN output may identify affected nodes but fail to explain the reasoning in useful engineering language. Fusion helps bridge that gap.

Use Case 5: When Engineers Need Decision Support, Not Just Search

Search answers the question: “Where is this mentioned?”

Design-Change Impact Analysis powered by a fusion model answers a harder question: “What else may be affected if this changes?” That distinction is critical. GNN+LLM fusion makes sense when the goal is not simply retrieval but decision support. For example:

• Ranking affected subsystems by risk
• Suggesting which simulations should be rerun
• Identifying missing verification coverage
• Summarizing prior similar changes
• Drafting an engineering impact report
• Recommending next workflow actions

The AI system should not replace engineering judgment. It should reduce the time and effort required for engineers to understand the consequences of change. As a practical industrial guide, GNN+LLM fusion is most useful when three conditions are present: the current design domain contains meaningful connected engineering objects, the impact of a design change may propagate indirectly across the objects in the design domain, and engineers/developers need an explanation that combines context, evidence and part change traceability. If there exists a simplistic task that only requires document lookup, direct database querying or deterministic rule integration, then implementation of GNN+LLM fusion is unnecessary and introduces additional cost and complexity.

II. When GNN+LLM Fusion Does Not Make Sense

Fusion is powerful in product design, but it is not always appropriate. Developers should not use advanced architectures simply because they are interesting; a system can be technically impressive and still be the wrong solution. Here are a few examples where a simpler approach will suffice.

Use Case 1: When Simple Retrieval Is Enough

If the user only needs to ask questions over documents, a Retrieval-Augmented Generation (RAG) system may be sufficient. Example: “Summarize the latest service bulletin for this controller.” This request may not require a GNN; a well-designed RAG pipeline with authoritative sources, access control, and citations may be enough. Use GNN+LLM fusion when the problem requires reasoning over connected engineering objects, not merely retrieving relevant text.

Use Case 2: When the Graph Is Weak or Unavailable

GNNs require meaningful graph structure. If the organization does not have reliable relationships among parts, requirements, tests, simulations, suppliers, manufacturing steps, and service events, a GNN may learn noise. In that case, the first step is not fusion; it is data preparation:

• Build or improve the knowledge graph
• Standardize identifiers
• Clean up relationships
• Resolve duplicate entities
• Validate links with domain experts
• Establish data ownership

We emphasize again that a bad graph does not become useful because a neural network is placed on top of it. In situations like these, development teams should treat the problem as a data readiness or a graph construction challenge rather than a standard graph model selection issue. A useful proof-of-concept pilot should first establish reliable key parameter identifiers, validate relationship parameters, and distinguish key objects. Once these parametric foundations exist, GNN-based methods can be evaluated for their ability to rank, infer or predict. Without them, the fusion may produce outputs that appear correct but are not trustworthy.

Use Case 3: When Deterministic Rules Are Sufficient

Some impact relationships are already well understood. For example: If Requirement X changes, notify the owner and rerun linked Verification Test Y. This may be best handled by rules, workflow automation, or database queries. GNN+LLM fusion is justified when the dependency structure is too large, uncertain, indirect, or dynamic for simple rules to cover.

Use Case 4: When the Decision Is Safety-Critical and Fully Automated

For safety-critical design changes, GNN+LLM systems should support engineers, not bypass them. A fusion system may help identify likely impacts and summarize evidence, but it should not automatically approve changes, override safety constraints, or make certification decisions without human validation. The appropriate model is “AI-assisted analysis + human engineering review + formal verification”; it is not AI said it, therefore release it.

Use Case 5: When Cost and Latency Outweigh Value

Fusion can be expensive. A full pipeline may include graph queries, GNN inference, document retrieval, LLM reasoning, tool calls, and human review. For low-risk or routine changes, this may be unnecessary. The best approach may depend on the request type:

Request Type	Recommended Approach
Simple document lookup	Search or RAG
Known dependency check	Rules or graph query
Local metadata question	Database query
Complex cross-domain impact	GNN + RAG + LLM
Safety-critical assessment	GNN + RAG + LLM + human review

Note again that the goal is not to use the most advanced architecture; it is to use the smallest architecture that produces trustworthy results. Figure 2 illustrates a decision-making flowchart for how developers should reason over the approach they want to take in solving complex problems using AI. The following section provides more details with a series of questions developers should answer before deciding whether or not a GNN+LLM fusion model is appropriate for the problem at hand.

Figure 2: The decision-making flowchart representing GNN, LLM, or GNN+LLM process steps.

III. Decision Framework for Selecting the Right Approach

Before choosing GNN+LLM fusion for any problem, developers should gather answers to the following questions:

Question	If Yes	If No
Does the problem involve connected engineering objects?	Consider graph modeling	Use search, RAG, or rules
Are indirect dependencies important?	Consider GNN or graph analytics	Use direct links or queries
Is relevant information spread across documents?	Add LLM + RAG	Use graph-only methods
Is traceability required?	Preserve graph paths and sources	Simple generated answers may be enough
Is the decision high-risk?	Add human review and validation	Automate cautiously
Is historical change-impact data available?	Use it to train or evaluate GNN ranking and change retrieval system	Start with graph queries, rule and expert reviewed outputs
Can recommendations be validated by experts of the design domain?	Deploy with a possible human-in-the loop feedback system with a measurable review criterion	Keep the system exploratory and get ready for data readiness until validation is possible

A simple rule of thumb: Use GNN+LLM fusion when the answer depends on both the topology of the system and the meaning of engineering knowledge.

IV. Why Design-Change Impact Analysis Is a Good Fusion Test Case

Design-Change Impact Analysis (DCIA) is the process of understanding how a proposed change to one part of a product, system, requirement, or manufacturing process affects other connected elements. The architectural flowchart in Figure 3 illustrates the steps in the corresponding analytical system. In Digital Industries, this problem appears everywhere:

• A change to an electronic control unit may affect wiring, embedded software, thermal behavior, compliance tests, and service procedures.
• A change to an aircraft subsystem may affect requirements, simulation models, certification evidence, supplier parts, and manufacturing processes.
• A change to an industrial machine component may affect mechanical interfaces, control logic, safety checks, spare parts, and maintenance documentation.
• A change to a manufacturing process may affect tooling, inspection plans, quality metrics, operator instructions, and downstream production schedules.

The difficulty is not simply finding documents that mention the changed part. The real challenge is understanding how the change propagates through the digital thread. This is where GNN+LLM fusion becomes valuable. A GNN can help identify and rank affected nodes and paths across a product or lifecycle graph. An LLM can interpret engineering documents, summarize findings, explain likely consequences, and generate a readable impact report. In other words, GNN helps determine where the impact may travel, whereas LLM helps explain what that impact means. Let’s consider a practical use case: changing the material of a motor mounting bracket from aluminum to polymer for a DJI Mavic 3 Pro drone. A graph query over the knowledge graph would identify the linked CAD part, assembly interface, fasteners and other necessary requirements. The GNN can then rank the resulting impact paths. The broader graph can also reveal thermal assumptions, inspection procedures and manufacturing fixture requirements. It can help to rank which indirect paths are most likely to be a high risk based on historical patterns through the learned strength metrics. Finally, the LLM can generate an engineer-readable impact report that explains the affected items, simulation-based evidence, uncertainties impacting decisions, and recommended actions.

V. Architecture Discussion and Practical Starting Point

For most DCIA applications, developers should start with modular fusion, not end-to-end fusion as illustrated in Figure 3. This approach is easier to test, govern, scale, and explain. End-to-end GNN+LLM fusion may become useful later, but it is usually not the best first implementation for industrial environments.

Figure 3: GNN+LLM architectural flow for DCIA applications.

The first implementation of this architecture should not attempt to perform DCIA across the enterprise. Better starting points include one product family/subsystem, one type of change request, one engineering team, one set of connected data sources, and one measurable workflow bottleneck. Good pilot examples in these cases include:

• Requirement change impact across requirements, tests, and simulation models
• Thermal subsystem change impact in an electric vehicle platform
• Wiring harness change impact across mechanical packaging and electrical architecture
• Manufacturing process change impact across tooling, inspection, and work instructions
• Service issue impact across parts, maintenance records, and design history

A narrow, measurable pilot study will tell us more about the validity of the approach than a broad, vague platform initiative.

VI. What a Useful Impact Report Should Include

A DCIA system should generate a structured report rather than an unstructured paragraph. A recommended format is:

Section	Purpose
Proposed change	Summarize the input change
Directly affected items	Components, requirements, tests, simulations
Indirectly affected items	Downstream or non-obvious dependencies
Risk ranking	Severity and confidence
Evidence	Documents, graph paths, prior changes
Recommended actions	Reviews, simulations, tests, approvals
Open questions	Items requiring human validation
Audit trail	Model version, data version, reviewer decisions

This structure makes the output useful for engineering review, collaboration, and traceability. As an example, let’s take a look at the same scenario where a user needs to change the material of a motor mounting bracket from aluminum to polymer for a DJI Mavic 3 Pro Drone. A useful impact report should explain the reasoning rather than a statement of “high risk”:

• Proposed change: Change motor mounting bracket material from aluminum to polymer.
• Directly affected items: Motor bracket CAD model, fastener interface, assembly requirement
• Indirectly affected items: Manufacturing fixtures, wiring clearance, thermal behavior, and vibration characteristics.
• Risk ranking: High risk à Vibration behavior; Medium Risk à Wiring Clearance; Low risk à Documentation update
• Evidence: Linked CAD assembly, prior change request history, retrieved engineering note
• Recommended action: Rerun vibration simulation, inspect wiring clearance and update maintenance documentation
• Open question: Would the modification affect flight stability in windy conditions?

VII. Challenges and Mitigation Strategies

Developers should expect several technical and organizational challenges when building GNN+LLM fusion systems.

Challenge 1: Defining the Right Graph

The most important early decision is not which GNN to use; it is deciding what the graph should represent. For DCIA, possible node types include requirements, components, CAD models, ECAD artifacts, simulation models, test cases, manufacturing operations, suppliers, service events, change requests, and software modules. Possible edge types include satisfies, depends on, verifies, manufactured by, supplied by, replaces, derived from, used in, affected by, and fails with. Note that a poor graph design leads to poor impact analysis.

Mitigation

Start with a focused graph schema for one high-value workflow. For example:

Engineering change request à affected component à linked requirements à linked verification tests à linked simulations à linked manufacturing operations

Do not try to model the entire enterprise in the first phase.

Challenge 2: Data Quality and Identifier Consistency

Design-Change Impact Analysis depends on reliable links. If part numbers don’t match requirements and simulations files, and document references are inconsistent, the system will miss dependencies.

Mitigation

Invest early in:

• Master data management
• Entity resolution
• Identifier normalization
• Metadata standards
• Duplicate detection
• Version tracking
• Change history preservation

This early work determines whether the system becomes useful or merely works in demos.

Challenge 3: GNN Cost and Scalability

GNNs can become expensive when graphs are large, dynamic, or highly connected. For DCIA, it is often unnecessary to run GNN inference across the entire enterprise graph for every question.

Mitigation

Use staged filtering:

Stage	Method	Purpose
1	Rules and metadata filters	Remove irrelevant objects
2	Graph queries	Identify direct dependencies
3	Embedding search	Find semantically related objects
4	GNN scoring	Rank indirect or non-obvious impacts
5	LLM summarization	Explain results and recommended actions

The principle is: Use cheap methods for breadth and expensive models for depth. In a DCIA application, use rules, metadata, direct graph queries, and embeddings before invoking heavier GNN analysis.

Challenge 4: Premature Filtering

Down-selection reduces cost, but it can also remove important edge cases. In engineering, the most important dependency is not always the closest or most obvious one. A mechanical change may affect a wiring harness, which may affect an embedded controller, which may affect a safety requirement.

Mitigation

Preserve multiple types of impact paths:

• High-confidence paths
• Safety-critical paths
• Historically risky paths
• Low-confidence but high-severity paths
• Diverse or unusual paths

Do not let the model optimize only for average-case relevance.

Challenge 5: LLM Hallucination

LLMs can generate plausible explanations that are not grounded in actual engineering evidence. For Design-Change Impact Analysis, this is unacceptable.

Mitigation

Use graph-grounded RAG and ensure the LLM is generating recommendations only from:

• Retrieved source documents
• Validated graph relationships
• Known requirements
• Simulation or test records
• Explicit assumptions

The output should clearly distinguish verified impact, likely impact, possible impact, and requires review. This distinction is not cosmetic; it directly affects engineering trust.

Challenge 6: Explainability and Trust

A fused system can become difficult to explain. If engineers cannot understand why something was flagged, they will not trust it.

Mitigation

Preserve intermediate artifacts:

• Graph path used
• GNN score
• Retrieved documents
• Model and data versions
• Confidence level
• Human review decision

The final report should explain both the conclusion and the evidence chain.

Challenge 7: Validation

DCIA is hard to validate because the full consequence of a design change may not be known immediately.

Mitigation

Use multiple validation strategies:

• Compare against historical engineering change orders
• Test against known dependency maps
• Review outputs with domain experts
• Measure precision and recall of affected artifacts
• Track time saved per impact analysis
• Monitor false positives and false negatives
• Compare recommendations against eventual downstream rework

False positives waste time whereas false negatives create risk; developers need to measure both. Each validation area (for developers) requires appropriate validation metric for proper quantitative justification.

Challenge 8: Governance, Security, and IP Protection

DCIA often involves sensitive product data, supplier information, proprietary requirements, and safety-related documentation.

Mitigation

Build governance into the architecture:

• Role-based access control and secure retrieval
• Model and data versioning
• Audit logs and approved model endpoints
• Human-in-the-loop approval
• Output restrictions for sensitive programs
• Data residency compliance where required

Governance should not be added after the prototype. That is how prototypes become liabilities.

VIII. Additional Topic: Human-in-the-Loop Design

One topic that completes this series is the role of human engineers in the loop. A GNN+LLM system for DCIA should not be implemented as an autonomous decision maker. It should be designed as an engineering assistant that improves visibility, speed, and consistency. Human-in-the-loop design should include:

• Engineer review of high-risk recommendations;
• Feedback capture on false positives and false negatives;
• Ability to override or expand the impact graph;
• Clear distinction between evidence and inference;
• Escalation rules for safety-critical changes; and
• Continuous improvement of graph quality and model behavior.

The best systems will not simply answer questions; they will help engineers ask better questions. That is the real shift from chatbots and generative models to AI systems.

IX. Summary and Closing Thoughts

Across this four-part series, we explored the progression from concept to implementation:

• Part I: Why combining structural reasoning and language understanding is essential;
• Part II: What major GNN and LLM model families are available to developers;
• Part III: How proper implementation leads to successful industrial deployments; and
• Part IV: Practical applications and Challenges of GNN+LLM fusion.

For Digital Industries, the value of GNN+LLM fusion is not simply better AI responses; the value is better engineering decision support across the digital thread. For the DCIA use case, this means helping engineers understand how a proposed change may affect requirements, components, simulations, manufacturing, suppliers, service, and compliance evidence. The most important lesson is practical: Do not use GNN+LLM fusion because it is advanced; use it when the problem requires both system structure and engineering knowledge.

From an economic readiness point-of-view, fusion becomes economically attractive when engineering impact analysis requires multiple experts, design reviews take significant engineering time, missed impacts cause rework, product complexity exceeds human traceability capacity, and/or historical change data already exists. Fusion may not be economically justified when products are simple, changes are localized, impact analysis already follows deterministic workflows, or historical change records are sparse. When used appropriately, fusion can help create AI systems that are more grounded, more explainable, and more useful to the engineers responsible for designing, building, and maintaining complex products. It may also reveal latent patterns in design relationships, a topic that could be explored in a future fusion-focused technical paper. Developers interested in implementing effective AI systems should begin with focused use cases, strong graph foundations, grounded retrieval, modular architecture, human review, and measurable engineering value. That is how GNN+LLM fusion can move from interesting research to trustworthy industrial capability. Finally, I would like to thank our Ph.D. intern Manish Aryal for editing the article and creating the graphics. Note: This article was prepared with the help of AI.