How to Accelerate Water and Energy Pilot Projects with Data Context Tools
AI projects in food manufacturing have slowed due to large-scale data projects delivering limited payoffs, stymying momentum. The next wave of data system integrators is here, providing semantic labeling and data context services and accelerating innovative strategies.

Consumers are feeling the pinch with higher prices in 2026, but food processing and manufacturing plants have felt the strain with water and energy costs for the last decade. “15 to 30% of all plant operating costs are now due to energy,” said Pedro Medina, founder and chief data farmer at Haystack Data Solutions during a presentation at IFT FIRST 2026. “That is up from single digits just a decade ago, and it's actually predicted that industrial rates are expected to rise another 18% through 2028.” These statistics come from the U.S. Energy Information Administration’s (EIA) 2024 Power Survey and the Department of Energy’s Benchmark report, and accordingly, paint a dark picture for profits.
The last decade has seen plant and corporate management adopting energy and water efficiency programs, but applying these applications across the enterprise has been difficult. Within a company, food plants will vary in equipment, line design, software, energy sources and water agreements. This creates real challenges in applying a standardized rollout for energy monitoring.
However, machine learning and turnkey data services are maturing, and industry leaders have a vision for how historian data and SCADA information can be quickly transformed into semantic data – operations labeling – and add data context intelligence layers.
The Road to Data Context
Leaders in the food segment understand that the immediate goal of AI is to achieve semantic meaning – labeling – across equipment and line assets in operations. In essence, to apply common labeling to pumps, motors, variable frequency drives, conveyors, ovens and mixers that paves the way for a context intelligence layer – ontology – to understand the relationships among these assets.
Asset labeling with no real meaning for intelligence layers is not enough, according to David Ariens, founder of IT/OT Insider. “Teams discover the same physical measurement has different tag names, different units or different sampling rates across plants,” Ariens says. “What should be a simple cross-site comparison becomes weeks of manual mapping, and it's only when you try to use that data for analytics at scale that the cracks become visible.”
Below is an interview with Pedro Medina, founder and chief data farmer at Haystack Data Solutions. His company helps plants reduce energy and water costs by implementing turnkey data solutions to label assets and provide an ontology — or context layer — to drive real-world agentic AI intelligence.
The answers have been lightly edited for clarity and brevity.
FOOD ENGINEERING: Can a plant succeed with an AI energy or water pilot before it has standardized its data?
Pedro Medina: Yes, and I'd go further to say waiting for standardization is how most of these projects die before they start. The mistake is hearing "data foundation" and picturing an 18-month program that touches every tag in the plant. A first energy/water pilot project doesn't need this, as the focus should be one narrow scope and the historian you already own.
Unilever's Poznan foods factory is the case I keep pointing people to. They put Laminar's inline spectral sensors on top of the clean-in-place (CIP) loops and existing PLCs; nothing was ripped out. Poznan reports 20% faster cleaning, 10% lower utility use and approximately €100,000 ($115,647) a year saved on the line using raw production data with an AI layer on top.
Most data modeling requires 12 to 24 months of normal operating history, plus some record of what went wrong along the way. Most of these plants include AVEVA PI or Rockwell Automation FactoryTalk historians that nobody queries, and the data is unlabeled, uncontextualized and only generating heat on their historian servers.
Data context is needed so the AI model isn't guessing. An asset tag means nothing by itself but tie it to an asset, a product code, a shift, a work order and a CIP cycle, and now you have something a model can reason about; set up a historian-to-cloud and semantic layer sequence, and you can do it for one production line before attempting forty lines.
One thing that trips manufacturers is units. For a milling application, we had to pin down a hundredweight converts to bushels at 2.2 before any cross-plant number meant anything at all. If you're going to report energy or water per good unit, somebody has to decide what a good unit is before the first model runs.
FE: How should a company invest so they can scale energy savings across multiple plants?
PM: First, the pipeline and the semantic layer. Getting historian data into a cloud platform where it can sit alongside ERP, maintenance and quality data is the most underinvested layer in this whole stack, and it determines whether the next plant takes six weeks or six months.
We spent a good part of 2024 and 2025 moving a top North American wheat flour miller onto Microsoft Fabric — roughly 30 workspaces — domain by domain, with full semantic models built as part of it. The financial model alone came out around 51 tables, 548 columns and 800 million rows.
Microsoft Fabric IQ is a semantic intelligence layer that connects raw data, business meaning and automated actions. Fabric IQ is getting formalized right now, which I think is underappreciated.
Microsoft has previewed Fabric IQ with an ontology feature that lets you define once what a line, an asset and a batch actually are, then bind those definitions to the underlying data so people and AI agents work from the same vocabulary. We're using it for multi-plant work, and it matters a lot because a real ontology turns other plants into a configuration exercise instead of a new project.
FE: What “narrow” segments within the food plant could be “low-hanging fruit” for energy and water applications? Are managers identifying data from predictive maintenance buildouts in recent years?
PM: Predictive maintenance has proven itself out for many years. The concept has been around for a very long time and driven by machine learning, not AI, which is a key point that a lot of people overlook.
If you've invested in predictive maintenance, it's not a stretch to say, "Well, can we leverage this data for energy?" We worked with a large protein manufacturer on a project to build out a historian-to-cloud pipeline. Energy is enormously expensive in wet milling, and once we had the cloud setup and the historian-to-cloud pipeline in place, we began to unify and standardize PLC tags.
We had a conversation with the client about tracking energy consumption across every one of their assets. Their response was: Do we want to evaluate what the plant is using on a production basis on each run and get down to SKU and product level? With the buildout, they could start evaluating energy per batch and per SKU, and water per batch and per SKU. The data is there, so we’re currently working with the customer to get this data pipeline in place.
From our perspective, we have the context or at least a framework for contextualized data in place. So our vision is to build our own Energy Management System (EMS). With this AI technology in place, the company can now avoid middle-layer platforms, software and additional subscriptions and payments.
Looking for a reprint of this article?
From high-res PDFs to custom plaques, order your copy today!






