How Baker Hughes Turned Four Years of Fragmented Plant Data Into Root-Cause Answers

Summary

Diagnosing poor Overall Equipment Efficiency (OEE) meant cross-referencing incident logs, root cause analysis (RCA) reports, bad actor records, work orders, and functional location details. Baker Hughes used PuppyGraph to connect these five datasets, covering four industrial plants from 2019 to 2022, into one knowledge graph over existing Databricks Delta tables, without moving the data.

The team asked questions in plain language. AI agents wrote the graph queries. The answers ranked equipment classes by RCA-related losses and cost of unreliability, identifying compressors among the largest contributors across both analyses and helping prioritize targeted reliability work.

This article is PuppyGraph's summary of SPE-228135-MS, the Baker Hughes team's paper presented at the SPE Annual Technical Conference and Exhibition in 2025.

The Challenge: The Score Knew What, Not Why

OEE compresses three things into one score: availability, the share of scheduled time equipment is ready to run; performance, how fast it runs against its designed capacity; and quality, the proportion of good output. The score is good at telling a plant that it is losing productivity. It is silent about why.

Answering the why meant reaching into plant data such as predictive maintenance records, work orders, timesheets, root cause analyses, and event logs. Those lived in different systems, owned by different departments. Much of what mattered was free text: a maintenance note, an incident description. Sensor errors and manual entry mistakes undercut the rest, and some of it sat in legacy systems not built for modern analytics.

So the work fell to people, reading through large datasets by hand, one system at a time. That is slow and error-prone, and it delays the repair as much as the diagnosis. And when several factors interact, reading each system's records on their own can obscure the underlying cause.

A Knowledge Graph Over the Existing Tables

The answer was to stop reading those systems separately and connect their records instead. The team took five datasets covering four plants over 2019 to 2022, all held as Delta tables in Databricks, and built one knowledge graph over them. Each carries a different view of plant health:

• Incident logs capture unplanned downtime events, time-stamped and categorized by loss type, annotated with production loss in metric tons, financial loss in USD, and a text description of what happened.
• RCA reports add root-cause context for high-priority incidents, with reasons, severity ratings, and corrective or preventive actions.
• Bad actor records flag equipment that fails repeatedly and drives high production loss and maintenance cost, with the cost of unreliability and resolution status.
• Work orders document maintenance activity, including execution time, hours worked, and functional location.
• Functional location details identify the equipment the other four datasets refer to.

That last one is the common identifier. Functional location appears in all five datasets, which means a failure in the incident log can be linked to its RCA entry, its related work orders, and any repeat appearances on the bad actor list.

A knowledge graph makes those links explicit and traversable. For the graph layer, the team chose PuppyGraph over Neo4j, citing open-source flexibility and seamless integration.

"Although Neo4j is a popular knowledge graph solution, we used PuppyGraph due to its open-source flexibility and seamless integration capabilities."

N. Sengar et al., Baker Hughes, SPE-228135-MS

PuppyGraph is a zero-ETL graph analytics engine. It queries data directly from sources such as Databricks without requiring data movement, which the paper credits with reducing onboarding costs and improving performance. Unlike traditional knowledge graph solutions, it does not store the graph in a static format; it builds the graph virtually on top of existing data, here the Delta tables in Databricks. PuppyGraph connects to Databricks, maps those tables to nodes and edges, and the schema is defined either interactively in the UI or by uploading a JSON file.

The mapping itself is hub and spoke. Plant nodes connect to their functional locations, and each functional location becomes a hub linking out to incidents, RCA reports, work orders, and bad actor records. The result is a single connected knowledge graph of 203,845 nodes and 204,684 edges, in effect a digital twin of the four plants spanning equipment specifications, performance history, failure records, and work order details.

Of those nodes, 179,570 are work orders and 22,990 are functional locations. The rest are 1,128 incidents, 111 RCA reports, 37 bad actor entries, and the four plants.

Agents That Write the Queries

The layer above the graph is a set of specialized agents, each running on databricks-claude-sonnet-4, that convert a natural-language question into a Cypher query, run it against the graph, and return the answer. That is what lets an operational question be put to the graph without manual querying or specialized technical expertise.

Each agent answers a specific set of questions against one part of the graph: plant-level, asset-level, incident, RCA, work order, and bad actor agents, plus a summarizer that condenses what the others found and a visualization agent that writes and runs Python to produce plots. Each is guided by a structured prompt describing the graph schema, and each returns its reasoning in THINKING, PLAN, and CONCLUSION sections. The system can also hand back the Cypher it ran along with the output nodes and data, to support auditability.

The paper describes how a production deployment could work: the workflow triggered every time an anomaly such as a significant drop in production quantity is logged to the graph, or from a user interface where someone asks a specific question. For the results presented in the paper, the team asked specific questions around the events.

What the Questions Surfaced

Each answer below came from plain-language questions, against records that previously had to be lined up by hand.

High-loss equipment, ranked by plant. A single instruction asked the system, "For each plant, can you give me the top 3 categories of equipment types that led to highest RCA losses? Break down these losses by their corresponding incident ratings." RCA is conducted only for high-impact or recurring incidents, so this analysis concerns the most critical failures. The RCA agent aggregated across the RCA, incident, and asset datasets and ranked the results. Plant C surfaced as the highest-risk site, with over USD 71 million in RCA-related losses, led by compressors, fired pressure vessels, and unfired heat exchangers. Across all four plants, compressors and pressure vessels were consistently the most significant contributors.

Bad actors, by cost of unreliability. A second prompt asked, "For each plant, can you provide the number of bad actors categorized by equipment type along with their associated cost of unreliability?" Bad actor records flag assets that fail repeatedly and drive high production loss and maintenance cost, and each record carries a cost of unreliability. The graph spans 2019 to 2022, so the figures sit in that window. Plants C and D each logged 18 recurring underperforming assets, but the cost diverged sharply: roughly USD 532 million at Plant C against USD 145 million at Plant D. Ranked across plants, compressors (USD 351 million) and fired equipment (USD 272 million) dominated the total.

Maintenance activity during a production-loss period. Asked about production losses between July and September 2021, the work order agent returned common maintenance types, frequently problematic equipment, and the most affected functional locations.

In the RCA and bad actor analyses, compressors were consistently among the largest contributors, joined by pressure vessels in the RCA losses and by fired equipment and heat exchangers in the cost of unreliability. The paper names them as prime candidates for targeted reliability work. That prioritization came out of plain-language prompts rather than manual cross-referencing of five datasets.

What the Study Establishes, and What Comes Next

The study shows how a knowledge graph over existing tables, paired with agents that write Cypher, lets the team answer these questions in plain language across four plants and four years of records.

The source records often lacked clear actions, which limited prescriptive recommendations. Baker Hughes frames the work as a foundation, naming prescriptive analytics, additional data modalities such as images, and stronger security and access controls as the next steps.

Security update: The paper identified PuppyGraph's shared basic credentials as a limitation and called for SSO or OAuth. PuppyGraph 1.0.0, released in June 2026 after the study, added OAuth and OIDC single sign-on, role-based access control, and row-level security.

Source: N. Sengar, A. Jain, R. Elsinga, P. Rai, and A. Anand, Baker Hughes, "How to Leverage Agentic AI and Knowledge Graphs to Enhance Overall Equipment Efficiency (OEE)," SPE-228135-MS, 2025. Study details and findings come from the paper; the later security update comes from PuppyGraph documentation.