Wastewater analytics platforms promise earlier warnings than a weekly lab sheet can give. They ingest flow, level, and sensor data, run models against it, and return alerts about overflow risk, pump wear, or treatment drift. The output looks like a measurement because it arrives on a dashboard with a number and a color. It is not a measurement. It is an estimate produced by a model fitted to a set of conditions, and the file that explains how it was fitted is the part utilities most often fail to keep.
A recent trade item offers a useful prompt. Water Finance and Management reported that StormHarvester has appointed Colby Manwaring, a former CEO of Innovyze, as a board advisor, and the company said the onboarding "marks a major step in the company's plans to accelerate its growth in the United States" (Water Finance and Management's report on the StormHarvester appointment). The report says nothing about how StormHarvester's models are built, changed, or validated, and this article does not assume otherwise. The point is general. A vendor expanding its footprint usually means more sites, more customers, and more product changes, and each of those can alter what a model was tuned to see.
What the model was fitted to
Every analytics model carries an implicit calibration window, a period when its outputs were compared against measured conditions such as hand-checked level readings, grab samples, or pump run logs. The fit holds for the catchment, the sensor placement, and the operating rules that existed during that window. A change in any of those, from a rerouted interceptor to a new lift station schedule, moves the baseline. The model keeps producing confident numbers, and nothing on the dashboard says the baseline has shifted.
For a utility, this makes the calibration record a document rather than a setting. It should name the period used for fitting, the reference instruments, the people who approved the fit, and the date of each adjustment. Without that, a later alert cannot be traced to a cause. Staff are left choosing between trusting the output and overriding it on instinct, and neither choice is documented.
Separate the vendor's model from the utility's data
Two things are easy to blur: the model, which belongs to the vendor, and the observations, which belong to the utility. The observations are the raw sensor streams, the manual readings used to check them, and the maintenance logs that explain gaps. If the platform stores these only in its own format, the utility's historical record depends on the vendor's continued service. Ask in writing how historical data can be exported, in what file structure, and with what time stamps. Ask whether exports include the metadata needed to interpret them, such as calibration dates and replaced units.
Platform growth raises the stakes. A vendor adding customers across regions may update models on a shared schedule. A utility should know whether updates are pushed automatically, whether the vendor announces changes to alarm logic, and whether a prior version can run in parallel for a defined period. None of these questions assumes the vendor is doing anything wrong. They identify where a change could reach your plant without your staff knowing about it.
Where the field check fits
A model output becomes useful when staff can test it against something the model did not produce. That usually means a scheduled manual reading, a grab sample sent to the lab, or a visual inspection at the location the sensor covers. Log these checks next to the model's prediction for the same time. Over a season, the paired records show whether the model is drifting. The log also gives the utility a basis for requesting recalibration, instead of a general complaint that the alerts seem off.
Membrane and advanced treatment units raise the same issue with higher consequences. A model that flags declining performance on a reverse osmosis train is only as good as the feed water record behind it. Utilities without in-house membrane staff may rely on local RO specialists for diagnosis, and those specialists will ask for the same paired records: feed conductivity, pressure drop, and the lab results that match them. Keep those records in a form that does not depend on the platform.
What to write down this quarter
Start with one page per platform. List the fitting period, the reference instruments, the export format, the update policy, and the named person at the utility who approves model changes. Attach the last three paired field checks. Review the page whenever the vendor announces a change in ownership, leadership, or market focus, because such announcements can precede product changes. The announcement itself does not change a model. The record you keep is what lets you tell the difference.