Predictive Operational Risk for Water & Wastewater Networks.
We build predictive capability that gives water utilities warning of high-consequence events — asset failures, supply interruptions, pollution incidents — early enough to act. Telemetry, asset records, maintenance history, and environmental data are triaged rather than perfected, and every model is judged on the lead time it buys operations, not just its accuracy score.
Fragmented Silos
Legacy Utility systems and disconnected feeds.
Structure the Problem Before the Model
Triage the Data, Don't Gold-Plate It
Production Reality
Lead-Time-First Model Design
Lead-Time-First Model Design
Data Triage Over Data Perfection
Predictions Embedded in Operations
Industry-Specific Friction Points
Five Sources, No Shared Picture of Risk
Network telemetry, asset registers, maintenance history, environmental data, and incident records each live in their own system with their own standard of completeness. The signals that precede a failure exist — scattered, variably governed, and never assembled in time to matter.
Insights That Stayed in the Deck
Previous analytics produced isolated point findings — a study here, a pilot model there — that were interesting once and operational never. None of it became a capability that planners and control rooms use week in, week out.
Events Whose Cost Exceeds the Repair Bill
A burst main is counted in supply-interruption minutes; a pollution incident in environmental-regulator scrutiny and public trust. For high-consequence events, a prediction that arrives after the decision window has closed is indistinguishable from no prediction at all.
How the Utility delivery flow works
This technical flow diagram reveals how Unolabs treats Utility data to deliver governed, production-ready outputs.
Source Layer
Frame
Defining the high-consequence event classes, the interventions that could prevent or soften each one, and the lead time those interventions need.
Industry Logic
Readiness Triage
Scoring telemetry, asset, maintenance, and environmental sources for fitness per event class, with remediation scoped to what models actually require.
Model Build
Training and backtesting models per event class against their lead-time targets, with precision and recall reported class by class.
Activation
Operational Embedding
Wiring predictions into planning and operational workflows, and feeding actioned outcomes back into retraining.
How the work is engineered for Utility
Structure the Problem Before the Model
For each event class we map the drivers, the uncertainties, and the decision points where intervention is still possible — then set the lead time a useful prediction must deliver. The model brief is written from the decision backwards, never from the data forwards.
Triage the Data, Don't Gold-Plate It
Each source is scored for whether it is good enough for the event class at hand — not against an abstract quality ideal. Remediation effort goes only where a model genuinely needs it, which is how the first prediction ships in months rather than after a data-perfection programme.
Embed in Operations From the First Release
Predictions route into planning cycles and control-room workflows from day one, and every actioned or dismissed alert is captured as feedback. Adoption is engineered alongside accuracy, because a model nobody acts on has a recall of zero where it counts.
Where the Real Work Is
Model Ambition Has to Match the Evidence
Data richness varies wildly across a water company's estate: event-duration monitoring now covers storm overflows densely, while sewer condition and older asset histories are sparse and inconsistent. Pretending otherwise produces models that demo well and fail quietly. We set each event class's modeling ambition from what its evidence base can support today — and let the ambition grow as monitoring coverage and record quality do.
The Lead-Time / Accuracy Trade Is a Business Decision
Predicting an event just before it happens is easy and useless; predicting it early is valuable and uncertain. Somewhere between sits the operating point where warning arrives inside the decision window at a false-alarm rate field teams will tolerate. We surface that trade-off explicitly per event class and let operations — not the data science team — choose where on the curve to run.
Built for a Platform That Is Still Moving
The models land on an estate that is mid-transformation — legacy systems retiring, a newer platform maturing, monitoring density rising under regulatory pressure. So everything ships portable: versioned features, documented assumptions, retraining procedures your engineers can run, and interfaces owned by named operational teams. The capability is designed to survive both the platform's evolution and our exit, with adoption by planners, control rooms, and field managers treated as a first-class requirement.
Visible work products, not vague advice
Each deliverable is designed to be used by Utility architects, engineers, data owners, and operations teams after the engagement ends.
How We Measure Predictive Value
A predictive capability earns its keep when operations act in time, not when a notebook reports a high score. These measures are agreed with your operational leads before the first model is trained, and reported per event class.
Lead time achieved versus lead time required
Median warning interval before each event class, compared against the time its intervention actually needs — the single measure that separates actionable prediction from retrospective explanation.
Precision and recall by event class
Reported class by class with the false-alarm burden alongside, never blended into one flattering aggregate — a pollution-incident model and a burst-risk model earn trust separately.
Share of alerts actioned by operations
Proportion of alerts that trigger an inspection, intervention, or planned-work change, tracked over time — the bluntest available test of whether the capability is embedded or ornamental.
Time to explain a model decision
Elapsed time to produce the inputs, features, and reasoning behind any given alert, because a model supporting regulated operational decisions must answer questions faster than a review can escalate.
Frequently Asked Questions
Our data is patchy and inconsistent. Should we fix it before modeling?
No — triage it, don't perfect it. Readiness is assessed per event class, and remediation is scoped to exactly what the first models need. Waiting for a clean estate delays warning capability by years, and much of what a perfection programme would fix turns out not to matter to the models at all.
Who retrains and owns the models after you leave?
Your teams, by explicit design. Retraining procedures, feature definitions, and monitoring thresholds are documented and rehearsed with your engineers during the engagement, and ownership of each model transfers to a named team before exit. Sustainability inside your operating model is a deliverable, not an aspiration — there is no ongoing dependency on us to keep predictions running.
How do you stop this becoming a black box operators ignore?
Explainability and adoption are built in from the framing phase. Every alert carries its contributing signals in operational language, false-alarm tolerance is set with the field teams who bear it, and the actioned-alert rate is tracked as a headline measure. When operators can see why a model flagged an asset, challenge it, and watch it improve, it becomes an instrument they trust rather than a verdict they receive.
How an engagement starts
Start with one event: pick a high-consequence incident from the past year, and we run a working session reconstructing what your data showed in the hours and weeks beforehand — what lead time was theoretically available, and what it would take to surface it next time. That session scopes the first event class.
Interested in the full industry blueprint?
We have deeper technical documentation for Enterprise Predictive Intelligence & Decision Forecasting for Utility in the Utility sector.
Bring last year's worst incident. We'll map what data could have bought you lead time.