Why the most consequential role in digital water is neither a data scientist nor a process engineer, and what happens at a plant when someone can be both
A role that sits between two disciplines
Most wastewater treatment plants already have the two competences that digital water is supposed to require. They have process people who understand biology, hydraulics, and what the plant does when the influent changes overnight. And, increasingly, they have access to data people, whether internal IT, a corporate analytics team, or an external provider, who understand models.
What is usually missing is the person who can hold both at once.
That person has a job title that barely existed a decade ago: water data engineer, or water systems data engineer. It is not a rebranded data scientist, and it is not a process engineer who has learned Python. It is a specific combination, and the reason it matters is straightforward. In wastewater, a model that fits the data is not automatically a model that describes the plant. Telling the difference requires knowing both the data and the process.
What the work actually involves
The public image of predictive analytics is the algorithm. In practice, that is the smallest part of the work.
A typical starting point is a historian export. Several hundred tags. Inconsistent sampling rates, some at one minute, some at one hour, some only when a value changed. Tag names that made sense to whoever configured the SCADA system fifteen years ago. Units that are not always documented. Gaps where an instrument was offline, and worse, stretches where an instrument was online but drifting. Alongside that, a laboratory record with a different timestamp convention, a different frequency, and sampling points that do not map cleanly onto the sensor locations.
Before any model exists, someone has to reconcile all of it. That means deciding what a missing value means in each specific case, whether a sensor reading is plausible, and which laboratory sample corresponds to which moment in the process, accounting for the hydraulic residence time between the sample point and the sensor that is supposed to explain it.
Then comes the part that determines whether the model works: choosing which parameters and which time windows actually carry information. Load that enters the plant at 02:00 does not affect effluent nitrogen at 02:00. It affects it hours later, through an equalisation basin, a biological stage, and a clarifier, each with its own retention behaviour. Getting those lags right is not a statistical exercise. It is a process engineering judgement expressed in data.
This is the core of the role. The algorithm is largely standard. The feature engineering is where plant-specific knowledge is encoded.
Why domain knowledge is not optional
Wastewater data is unusually rich in correlations that are real, stable, and useless.
Conductivity tracks a production schedule. Temperature tracks the season. Flow tracks rainfall. A model can find any of these and produce a respectable error metric on historical data while learning nothing about the treatment process. It will then fail the first time operating conditions move outside the range it was trained on, which in wastewater is a matter of weeks, not years.
Someone with process knowledge catches this. They know that a strong statistical relationship between two variables can reflect a shared upstream cause rather than a mechanism, and they know which mechanisms are physically plausible. This is also why Liquisens constrains its models with process physics rather than letting them fit freely: the constraint is a way of encoding what the water data engineer knows, so that the model cannot learn a relationship the process does not permit.
The same knowledge is what allows an honest statement about uncertainty. If a plant has thin instrumentation on a critical stage, model precision will be lower. A water data engineer can say so, specify what additional data would change that, and quantify the trade-off, rather than presenting an unqualified number.
Explainability is not a software feature
There is a growing argument in the sector that AI tools for water must be explainable by architecture rather than explained after the fact. Writing in Smart Water Magazine in March 2026, Marcello Serrao draws the distinction precisely: a conversational interface that renders a black box’s output in plain language is not the same thing as a model whose reasoning is transparent by construction — one translates the black box, the other dismantles it. He makes the case for hybrid architectures in which mechanistic process knowledge provides the structure and the machine-learning layer handles what the equations cannot represent, and he argues that explainability should appear in procurement specifications for digital water tools rather than being treated as an optional extra.
We agree with the conclusion. We would add the part that is usually left out: the physics in a physics-informed model does not install itself.
Someone has to decide which mass balances apply to this plant, which biological mechanisms are plausible at this temperature and this sludge age, and which of several hundred available signals belong in the model at all. Someone has to recognise that a stable correlation between conductivity and effluent COD reflects an industrial discharger rather than a treatment mechanism, and exclude it. Those decisions are the physics constraint. They are made by a person with both process and data competence, before any training run begins.
This is why the explainability debate and the staffing question are the same question. A utility can write explainable AI into a tender. What it actually receives depends on whether the supplier has people who can encode process knowledge into the model, or only people who can attach an explanation layer to one that was fitted blindly.
What the role is worth to a treatment plant
The value shows up in the safety margins operators carry.
Plants run conservatively because feedback is delayed. Chemical dosing stays above what is theoretically needed, aeration runs longer than demand justifies, and setpoints stay tight long after conditions have stabilised. That behaviour is rational when the cost of a violation exceeds the cost of excess. It is also a permanent operating expense that rarely appears as its own line item.
A well-built plant-specific model reduces that expense by making the near future visible. In a project at a large municipal plant in France, models built only from existing SCADA data predicted COD with an error of around 8 percent, within the analytical uncertainty of the laboratory method itself. Extended to BOD, suspended solids, total Kjeldahl nitrogen, total nitrogen, and phosphorus, errors ranged from 8 to 25 percent, comparable to or better than typical laboratory uncertainty for those parameters. Applied to denitrification dosing on a six-hour predictive horizon, the result was a 32 percent reduction in chemical consumption while total nitrogen violations decreased rather than increased.
No new hardware was installed. The difference was entirely in how existing data was engineered and interpreted.
Why plants rarely employ one, and what follows from that
Here is the uncomfortable part of the argument.
The skill profile is scarce, and the demand pattern inside a single plant is a poor fit for a permanent position. Building the first plant-specific model is intensive work over weeks or months. Maintaining it afterwards is not. A utility that hires for this creates a role that is oversubscribed during the build and underused afterwards, while competing for a candidate the wider technology sector also wants.
The alternative, buying a generic analytics product, fails for the reason described above. A model trained on one facility does not transfer cleanly to another, because two plants receiving comparable wastewater can behave very differently. Software without the engineering judgement embedded in it produces dashboards, not decisions.
The practical resolution is that the capability is accessed rather than hired: the water data engineer works across plants, and the plant retains the resulting site-specific model.
How Liquisens Predict is built around the role
Liquisens Predict is structured to make that work repeatable without making the output generic. The internal data engine is standardised; the model produced for each plant is not.
The sequence reflects the role directly. Data intake from historian exports, with no process changes. Site-specific model training. Correlation of SCADA signals to laboratory-measured quality indicators. Data engineering to determine which parameters and time windows capture the plant’s dynamics. Then a step that is easy to skip and expensive to skip: alignment with operators and process engineers, who explain the correlations that are not obvious and label the events the data alone cannot classify. Refinement follows, and only after validation does the model move to real-time decision support.
Step five is where the role stops being technical. Operators know which anomaly was a genuine upset and which was a cleaning cycle. They know which correlations reflect a habit rather than a mechanism. A water data engineer who cannot elicit that knowledge, or who does not think to ask, will build a model that is statistically sound and operationally wrong.
The same principle governs deployment. Optimisation boundaries are defined together with process engineers, environmental advisors, and plant operators. The model proposes; the plant decides.
That is also the practical answer to the adoption problem. A recommendation an operator cannot interrogate will be overridden, and a model that is overridden produces no value regardless of its accuracy.
The role, not the tool
The interesting shift in digital water is not that models became available. It is that a role emerged whose function is to make plant knowledge and plant data describe the same system.
Utilities under tightening performance requirements will not close the gap with dashboards, and they will not close it with algorithms alone. They will close it with people who can read a historian export and a treatment train at the same time, and with tools built by those people rather than around them.