Heavy industry gets more value from organizing and documenting its data than from rushing advanced AI into high-risk equipment systems.
2
A control philosophy can give data scientists the business context, diagrams, operating rules, data-quality needs, and failure conditions required to work on the right problem.
3
AI products in industrial settings need shared diagrams, standard operating procedures, critical metrics, and emergency responses so teams can understand and manage failures.
Summary
Richard Howes describes how oil and gas, forestry, manufacturing, and other heavy industries use ML and AI around equipment, compliance, documents, imagery, and operational data. Preventive maintenance is often a batch process tied to planned plant shutdowns, while some drilling and embedded-controller applications need near-real-time analysis. He argues that the main advantage these companies can build is organized, usable data, since models and technology are increasingly available elsewhere. A control philosophy, adapted from industrial engineering, can document the business process, control narrative, diagrams, optimization goals, data quality, and responses to failure. This gives data scientists enough context to test whether a proposed use case is useful and feasible before they build it. Richard also connects AI quality to business outcomes, compliance, and risk. Poor documentation and changing inputs can make a downstream ML or RAG system worthless, while better data practices may remove the need for the model altogether.
Heavy-industry AI ranges from embedded sensors to document assistants
Richard describes heavy industry as oil and gas, forestry, manufacturing, and other operations with large amounts of equipment. Current applications range from IoT devices measuring sound for workplace safety to enterprise chatbots and RAG systems that help people understand data. Common use cases include preventive maintenance and QA/QC for regulatory compliance. Regulations around energy, emissions, and carbon reduction change often, so a simple RAG bot can help teams understand new requirements and identify policy or procedure changes. The work still has to reach the people doing the job quickly because industrial change management affects large teams.
Preventive maintenance is often a scheduled batch process
Preventive maintenance is not always a continuous prediction problem. Richard explains that a gas plant may plan a yearly turnaround and use equipment history and control-system data to decide what needs replacement while the plant is already offline. Getting this wrong can force another shutdown and cost production time. Maintenance teams need to identify critical components and failure points before committing to a substantial outage. Richard has not seen ML widely used to identify those critical components yet, although he expects that application to develop.
Industrial data is more valuable when it is organized before advanced models arrive
Richard says heavy-industry companies cannot control which open-source models other organizations produce, so their practical advantage is to mine, understand, and store their own data. Much of that information is scattered across PDFs, SharePoint sites, desktop folders, and other local sources. Equipment identity and documentation are especially important during troubleshooting. A plant may contain many control systems, but losing time finding the right manual can directly reduce production. As-built documentation may not match what was installed, and workers may still need to search by serial number and manufacturer. Organizing this material into a usable repository or knowledge graph would make later AI use cases easier to test.
Industrial control diagrams offer a model for explaining complex AI systems
Control systems are built from modular PID loops, which can be tested separately before they are connected into a larger plant. Richard points to the piping and instrumentation diagram as the shared artifact that lets maintenance staff, managers, operators, and automation specialists understand how a plant works. He suggests that complex AI and ML products need a similar end-to-end diagram. It should show inputs, outputs, intermediate stages, dependencies, and what each group is optimizing. Business stakeholders can define the desired output and timing, while technical teams can document the system details. The diagram gives people a common reference when they troubleshoot or discuss changes.
A control philosophy gives data scientists context before they explore a database
Richard compares a control philosophy to the context supplied to an LLM. In a gas plant, the document explains operating principles, the control narrative, diagrams, responses when things go wrong, scalability, and data quality. He uses the same idea when sending data scientists to explore a database with hundreds of tables. Rather than asking them to discover the business objective from raw data, he gives them the system, process, optimization goals, and constraints first. The team can then add to that body of knowledge. Data scientists and engineers can also challenge the proposal when the required data is unavailable, the source is disconnected, or the proposed path from one stage to another cannot work.
AI quality depends on business outcomes and failure planning
Richard connects AI quality with the outcomes a business needs, rather than only with the model or data platform. Teams should identify the metrics that matter, the conditions that indicate failure, and the action to take when those conditions occur. Possible actions include reverting to another version or starting triage. Industrial facilities already create emergency response plans for potential failures, and Richard argues that AI products delivered at scale need comparable procedures. A shared diagram and documented operating procedures reduce dependence on one engineer who happens to know the system and help stakeholders understand what was considered before they approve a high-risk use case.
Poor source data can make a downstream ML system unnecessary
Richard says AI and ML are sometimes used as a Band-Aid for poor data quality. If an algorithm is meant to classify four classes but its input accepts inconsistent numbers, letters, or arbitrary text, the output will be garbage. The better answer may be to fix the upstream platform so it produces the required four values. Once the data is controlled, the classification model may no longer be needed. RAG systems create a similar pressure because outdated or incomplete documentation can make a chatbot useless. Richard sees value in these failures because they force the business to examine and document the data behind its processes.
"If you can bring comfort to them, being like I did my due diligence, I got these diagrams, I got what does a shutdown look like, what catastrophic things can happen potentially, if you can show and demonstrate that you've thought these things through, we got some risk mitigation in place."Richard Howes31:04
Who should watch
You are building ML or AI products for factories, energy, forestry, infrastructure, or other operations where failure can cause downtime, safety problems, or environmental harm.
Your data scientists keep discovering business constraints late because the source systems, documents, and process goals are unclear.
You need a practical way to explain an AI system to operators, managers, engineers, compliance staff, and the people responsible for responding when it fails.
