I. "We are engineers, not IT guys." – A paradox that won't let me rest

Lately, I have discussed a recurring theme with board members, managing directors, and engineering heads – sensory and automation providers, mechanical engineering, and automotive. One topic consistently stands out.

On one hand, executive leadership agrees: product development must speed up. Lead times, cost pressure, talent shortage, geopolitical competition – the reasons vary, but the goal is identical. Almost everyone expects agentic AI to help: AI systems that do not just answer questions but independently handle engineering tasks.

At the same time, these decision-makers know two issues plague engineering: hallucinations and data availability. A language model suggesting a plausible but wrong tolerance is embarrassing in marketing, but dangerous in design. Consequently, I hear executives say: "A knowledge graph is becoming essential for our engineering."

And here is the paradox: when I want to discuss knowledge graphs with CTOs or heads of engineering, they often reply: "That's too abstract for me. We are engineers, not IT guys."

I understand this reflex. The term sounds academic, and standard explanations overflow with jargon like "ontology", "RDF", and "semantic triples". But the knowledge graph is not just an IT topic. It is an engineering priority – perhaps the most important one for the coming years. It answers a daily question for every design manager: How do we systematically reuse the knowledge trapped in our products, projects, and minds?

In this article, I explain what a knowledge graph is using engineering language, the core problem it solves, and its practical applications. We will use a concrete example: a custom assembly system from special machinery manufacturing.

II. The practical example: custom assembly line in ETO business

Imagine a special machinery manufacturer building assembly systems. Their business: engineer-to-order (ETO) lines. An industrial customer requests an assembly line for a new electromechanical unit with twelve stations: feeding, joining, press-fitting a bearing bush with force-displacement monitoring, screwing, greasing, and EOL testing. The specification document spans 120 pages with hundreds of requirements: cycle time ≤ 12 seconds, availability ≥ 98% based on customer-defined calculations, component-level traceability, a cleanroom class for two stations, and MES integration.

Each of these lines is unique, yet contains mostly proven elements. A Fraunhofer presentation noted that in special machinery, typically 80% of components can be configured, 15% reused, and only 5% designed from scratch. The exact ratios vary by product and company, but it matches my project experience. Base frames, workpiece carriers, transfer systems, pick-and-place units, screwdriving spindles, presses, and testing equipment are standard. A typical line contains thousands of parts, mostly purchased parts, with some custom designs.

In most companies I speak with, the process looks like this: sales and estimation team members manually review specifications, transfer requirements to a concept document in Word, and estimate costs in Excel. After order confirmation, order-specific design starts from scratch. Whether a similar press-fit station already exists depends entirely on team memory. The standard phrase is: "Ask Herbert, he designed something like that in 2019." If Herbert is on vacation, you redesign it. If Herbert retires, you redesign it forever.

This causes high manual engineering effort, minimal systematic reuse of knowledge and parts, growing part variety, long lead times, and designers spending half their day searching, asking, and reinventing.

III. What is a knowledge graph?

Every mechanical engineer already works with a graph daily: the bill of materials (BOM). A BOM is a network of nodes (assemblies, parts) and relations. It is dominated by one connection type: "consists of" or "uses". The line contains station 06, station 06 contains the screwdriving unit, and the unit contains the screwdriving spindle.

A knowledge graph generalizes this idea: it is a network of nodes and relations with different, domain-specific, and consistently defined connection types. Besides "consists of", it includes: "fulfills requirement", "limited by", "is variant of", "is compatible with", "was verified by", "is similar to", or "was selected because".

Applied to our assembly line, a small section of the graph looks like this:

Requirement R-217 "cycle time ≤ 12 s" → applies to → assembly line → broken down into → allowable station cycle times. Station 06 "screwdriving" → has measured cycle time → 10.8 s → verified by → acceptance protocol P-4711.

Station 06 → uses → screwdriving spindle EC-8. Screwdriving process SP-06 → has nominal torque → 8 Nm → has tolerance → ± 5%.

Station 06 → is variant of → screwdriving station from project M-2022-134 → designed by → designer H. → documented in → design calculation AR-0815.

Two points are critical here.

First: Knowledge resides in relations, properties, rules, and arguments, not just in objects. ERP systems know that the EC-8 spindle exists. Requirements tools hold R-217. But how R-217 was broken down for Station 06, that Station 06 is a variant of a 2022 project, and why that specific spindle was chosen – these connections are usually missing from our systems in a machine-readable format. Some links exist in isolated systems, others only in the project manager's head. An experienced engineer is a living knowledge graph. The goal is to make this relation-based knowledge explicit, permanent, and machine-readable.

Second: The graph is searchable. When you define relations explicitly, you can trace them across multiple steps. "Which active projects are affected by the end-of-life of spindle EC-8, and which customer requirements depend on it?" With a complete graph, this query takes seconds. Today, it takes a week of checking three systems and asking four colleagues.

That is all a knowledge graph is. No magic. It does not replace databases; it acts as a relational layer above existing systems, just as a BOM is a structural layer over parts.

IV. The core problem: knowledge exists, but relations are disconnected

Why can't current systems do this? Most companies have CAD, PLM, ERP, CRM, and requirements tools, often costing millions.

The problem has three layers:

Layer 1: Process fragmentation. Assembly line knowledge is scattered. Requirements live in PDFs or requirements tools. Concepts are in Word. Calculations are in Excel. CAD designs are in PLM. Materials and routings/work plans are in ERP. Commissioning insights reside in emails and service reports. Every system has its own numbering and versioning. Point-to-point connectors do not scale: ten systems require 45 potential connections.

Layer 2: Semantics. Even with technical connectors, terminology differs. "Variant" means one thing to sales and another to PLM. An "item" in ERP is not a "part" in CAD. The same press-fit station is "Joining 2" in the quote, "ST-06" in CAD, and "OP 40" at the customer site. Without a layer defining these terms, integrations stay fragile, and AI relying only on text similarity fails on complex engineering queries.

Layer 3: Implicit knowledge. Valuable engineering knowledge is rarely documented. Why did we replace the pneumatic press with a servo-electric one in 2022? Why shouldn't workpiece carrier B combine with transfer system C? These design decisions leave when employees retire, which is a massive risk for engineering departments.

The core challenge: Engineering is a knowledge-intensive, highly connected process running on systems optimized for specific tasks. PLM manages product structures, files, and changes. ERP manages materials, routings/work plans, and procurement. But cross-system relations and design rationale are lost. The knowledge graph provides a unified place for these connections.

This is not just my opinion. Academic reviews on knowledge graphs in manufacturing highlight data heterogeneity, lack of interoperability, and incomplete knowledge capture as the primary problems graphs address.

V. Walkthrough: The customer inquiry with a Knowledge Graph

How does the RFQ process work with a well-structured knowledge graph?

Step 1: Mapping requirements to product features

The system reads the specifications and links each requirement to a node in the graph using typed connections to the product platform, rather than just text similarity. "Cycle time ≤ 12 s" connects to the cycle time attribute of the assembly line class. "Press-fitting with force-displacement monitoring" links to the joining/pressing station class and its attributes like pressing force, monitoring method, and documentation requirement. Requirements without a match in the platform are flagged as custom, showing exactly how much non-standard engineering is required.

Today, an estimator spends days on this in Excel. In a graph, it is explicit, verifiable, and linked to the project forever – right through to acceptance testing, where every requirement maps directly to the test protocol.

Step 2: Configuring standard components

For standard and configurable requirements, configuration rules take over. This leverages the graph's strength in variant engineering. Usually, compatibility rules live in spreadsheets or in people's heads: workpiece carrier B does not fit transfer system C; forces above 20 kN require frame class 3; cleanroom requirements exclude pneumatic assembly X.

In spreadsheets, rules break when new product lines are introduced. A graph represents them as they are: a network. "Is compatible with", "excludes", and "requires above threshold" are managed centrally. The graph hosts components, attributes, and dependencies. Rules then derive valid combinations. Changing a rule happens once, applying to all future configurations. For our assembly line, the frame, transfer system, workpiece carriers, and standard stations are configured automatically and checked for compatibility.

Step 3: Reusing existing solutions

This leaves features that are neither standard nor configurable. Usually, this is where custom design begins. Here, similarity search helps in two ways.

First: Functional similarity in the graph. Finding if a design problem was solved before becomes a query about functions and physical principles, not file names. Instead of searching for "Press_station_final_v3.prt", we query for: a station that joins, using force-displacement monitoring, for a part with an interference fit H7/s6 in the relevant diameter range, with cycle times under 12 s. Since past projects are linked in the graph, a similarity model finds the stations from 2019 and 2022, even if the original designer has left the company.

Second: Geometric similarity via 3D models and 2D drawings. For custom manufactured parts like fixtures, adapter plates, and gripper fingers, we search existing inventory for similar geometry before creating new parts. Geometric and functional similarity complement each other. Geometry finds the part; the graph provides the context – associated routings/work plans, tolerances, design rationale, and commissioning reports.

The result: Only a fraction of the machine is truly custom

This process splits the project: most of it is configured, another part is adapted from past designs, and only a small portion requires new engineering. This is crucial because a few custom components often drive most of the engineering effort and risk. That is where design time belongs – on the true innovations that differentiate you, not on redesigning adapter plates.

VI. Why knowledge graphs provide the context for reliable Agentic AI in engineering

Back to our initial paradox: everyone wants agentic AI, but fears hallucinations. A knowledge graph bridges this gap.

A language model relying only on text similarity struggles with engineering. Engineering questions require multi-step reasoning. Asking "Which spindle for Station 06?" requires a chain: Requirement → Station → Torque Range → Controller Compatibility → Delivery Status. Text search cannot reliably trace these steps. A graph provides these dependencies. The AI then answers using verified paths and subgraphs, querying databases or calculation tools as needed. It can also generate the reasoning: This answer is based on requirement R-217, compatibility rule K-88, and acceptance protocol P-4711. This makes every calculation verifiable.

This is backed by recent research:

• Studies show many generative AI pilots fail to scale because they lack integration and access to company-specific context. The models are fine; they just lack the context of your engineering data.

• In enterprise QA benchmarks, representing databases as knowledge graphs increased answer accuracy from 16% to 54%. Microsoft Research reports that its GraphRAG approach uses 26% to 97% fewer tokens than baseline methods by guiding the AI directly to relevant relationships instead of searching through raw documents.

• Gartner predicts that over 40% of agentic AI projects will be abandoned by 2027 due to costs, unclear ROI, and risk. In engineering, success depends on whether agents have a reliable context foundation.

A knowledge graph is not a magic source of truth. It does not eliminate hallucinations on its own. It explains answers and maps dependencies, but only as well as the underlying data. This is why versioning, sources, and approvals must be built into the system.

Simply put: Language models are commodities. Your product knowledge graph is not. Competitors can buy the same model. They cannot buy your formal knowledge of how your machines work, why they are designed that way, and how components interact. For ETO companies, the knowledge graph is not IT overhead – it is your core intellectual property in digital form.

VII. Who is doing this – and where the industry stands

An engineering question: Is this proven or science fiction?

Large companies like Siemens, Bosch, and automotive OEMs have worked on this for years. However, adoption across broader mechanical engineering is limited. Most companies I interview are between "never looked into it" and "ran a proof of concept that never went live". This is rarely a technology failure. Usually, projects fail because they are treated as massive IT initiatives ("let's spend two years modeling the whole company") or research projects without business value. Siemens recommends the opposite: start small, connect two or three data sources for a high-value use case, and let the graph grow as a coordination layer over existing systems.

For mid-sized companies, this is good news. You do not need an enterprise-wide graph to start. You just need one clear use case, like the RFQ process described above.

VIII. The challenges

Of course, there are challenges:

First: Engineers must define the knowledge model. IT departments or external consultants cannot define your product classes, attributes, and relationships. It requires design methodology, not coding. This is why the topic belongs to engineering leadership, not just IT. The good news: populating the graph is now largely automated, and modeling is straightforward when limited to one use case.

Second: Graphs expose data quality issues. Duplicate materials, inconsistent naming, and orphaned drawings will appear. Some argue for fixing data quality before starting AI. I believe this is incorrect. The graph is the best tool to clean data because it makes duplicates and contradictions visible and actionable.

Third: Knowledge needs versioning, validity, and lineage. In engineering, knowing how things connect is not enough. You must know which product version, project state, and timeframe a connection applies to. A spindle approved today might be phased out tomorrow. A compatibility rule might require software version 4.2. A production graph must store revisions, approvals, lineage, and responsibilities.

IX. Generating graphs automatically for engineer validation

A common objection is: "Who will maintain this? My designers have no time to enter knowledge." In the past, this was true. Manual data entry is why older knowledge bases failed. Today, the approach is different: we no longer build graphs manually. Systems extract suggestions from existing data, while engineers validate and refine the core domain knowledge.

Items, BOMs, and project assignments come from PLM and ERP. Language models extract requirements and limits from specifications, mapping them to the product platform. Shape analysis generates attributes and similarity links from 3D models and 2D drawings. Old project folders, calculations, and test protocols can yield connections between requirements and validated designs. For our assembly line, structural data and relationship proposals are generated automatically. Engineers only need to validate or add the most valuable relationships, such as design decisions and compatibility exceptions. Automation minimizes data entry, while human validation maintains quality.

Automation does not mean lack of control. It generates proposals, shifting the engineer's role: they no longer input data from scratch; they review and validate. The system presents extracted relationships with a confidence score: "Requirement R-217 linked to cycle time of Station 06 – High Confidence," or "Station 06 is likely a variant of M-2022-134 – Review Required." Engineers confirm or reject with a few clicks. This review fits into existing workflows, like design reviews or RFQ estimation.

This hybrid approach is proven in industry and research. A 2025 study in Information Processing & Management compared workflows between language models and domain experts for validating knowledge graphs. Hybrid workflows, where machines pre-screen and experts resolve uncertain cases, delivered the best balance of quality and effort. As a practical example, Bosch used ontologies and knowledge graphs to unify production, laboratory, and simulation data for resistance spot welding. Using predefined templates, welding experts input their domain knowledge without writing code.

Another aspect is annotation. When an expert has undocumented knowledge, they can add it as a link: "Selected because customer requested X," or "Do not combine with transfer system C due to 2021 commissioning issue." This takes seconds but remains accessible forever.

X. How it fits together at wailand

If you have followed our updates on 3D similarity search, 2D drawing analysis, workflow automation, and standard connectors, you might wonder how they connect.

The knowledge graph is the center of our architecture. In our platform, it works like this:

The Integration Layer connects CAD, PLM, ERP, MES, and Excel via standard connectors. It supplies the graph with raw nodes: items, projects, requirements, documents, and routings/work plans. The graph is the relationship layer between these existing tools, not a replacement.

The Service Layer provides the AI services – specifically 3D similarity and 2D drawing analysis. They generate nodes and connections missing from source systems. Drawing analysis breaks drawings into features with unique IDs. 3D analysis generates geometric similarity links across your inventory. Every analyzed part enriches the graph, improving future queries.

The Knowledge Layer is the graph itself: the connected product knowledge across systems – requirements, attributes, components, rules, standards, and projects. It provides explicit context and dependencies for AI agents, replacing simple text search.

The Workflow Layer turns this into automation. The RFQ process from Section V is automated: read specifications → map requirements to attributes → configure → search similarity → flag custom scope. Where judgment is needed, the engineer decides. Where routine tasks dominate, the workflow takes over. AI agents work on verified graph data and rules, not guesses.

Our release sequence is logical: first, we supply tools that deliver immediate value and populate the graph (similarity, drawing analysis, connectors), then we enable end-to-end automation built on this knowledge network. The knowledge graph is a planned output of automations that pay for themselves individually, not a massive upfront investment.

XI. Summary

The knowledge graph is a practical engineering tool. It models the relations that often exist only in your best employees' heads – between requirements, attributes, components, rules, and projects. For ETO and CTO companies, this relationship knowledge determines whether an RFQ becomes a solid concept in days or weeks, and whether designers focus on core innovations or redesign standard parts.

It is also the foundation for reliable, hallucination-free agentic AI in engineering. To work reliably, AI agents need verified knowledge, rules, calculations, and tools.

The graph provides this explicit, cross-system knowledge base, making search, configuration, rules, workflows, and AI agents far more dependable.

My advice to engineering leads who think "we are engineers, not IT guys": because you are engineers, this is your priority. IT can run the servers. Only you can model your products.

If you want to discuss a targeted first use case in your company – from requirements mapping to similarity search – let us connect.