Client
A UK environment agency responsible for river and coastal flood risk monitoring and public flood warning across a multi-catchment region
Sector
Public Safety & Emergency Services
Engagement
Live flood risk data platform linking river gauge telemetry, upstream rainfall forecasting and multi-channel warning dissemination into one shared operational view - multi-quarter programme.
What the client needed
The agency operated a dense network of river and coastal gauges, each reporting water level on its own polling cycle into a regional monitoring system built up catchment by catchment over two decades. Duty officers watching a fast-rising catchment had to check gauge readings, a separate rainfall radar feed and a third upstream forecasting model as three different screens, then manually judge whether a threshold breach downstream was imminent before authorising a public warning. That judgement call sat with whoever was on shift, using whichever combination of systems they were most familiar with, and the agency's own review of recent flood events found the average time between a trigger gauge crossing its flood threshold and a warning reaching affected households ran past four hours in fast-response catchments - catchments specifically defined as ones where river levels can rise from normal to dangerous in under six hours. In the events that mattered most, that gap consumed most of the available response window before a single warning had gone out.
How we worked
- Built a live ingestion layer pulling gauge telemetry, upstream rainfall radar and the agency's existing hydrological forecast model into one time-aligned view, rather than asking duty officers to mentally reconcile three separate screens.
- Modelled each catchment's known response time - the interval between upstream rainfall and downstream threshold breach - so the platform could surface a predicted breach window, not just a current reading.
- Connected the live view directly to the agency's existing multi-channel warning dissemination service, so an authorised warning could be issued from the same screen showing the trigger, instead of a separate handoff to a communications team.
- Built an explicit human authorisation step into every warning trigger, since the brief was explicit that no threshold breach should generate a public warning without a duty officer's sign-off.
- Ran the platform in shadow mode alongside the existing three-screen process through an entire wet-season cycle, comparing its predicted breach windows against what actually happened before it became the primary tool.
- Trained duty officers across all regional control rooms on the unified view, since the timing gain only holds if every shift uses the same system rather than falling back to catchment-specific habits.
Measured results
All figures verified with the client. Specific site, catchment and personnel detail withheld in line with our standard confidentiality terms and public sector information-sharing requirements.
- Average time from a trigger gauge crossing its flood threshold to a warning reaching affected households fell from over four hours to approximately 22 minutes in the fast-response catchments the programme prioritised.
- The shadow-mode comparison against a full wet season found the platform's predicted breach windows matched actual breach timing within the agency's existing forecast accuracy tolerance in the large majority of tracked events.
- Duty officers report materially less time spent manually cross-referencing gauge, radar and forecast screens during live incidents, freeing attention for judgement calls the platform can't make.
- The shadow period surfaced a specific gap in one catchment where the existing forecast model's response-time assumption was measurably out of date against recent land-use change - now flagged for hydrological review rather than silently under-predicting.
- The agency is extending the same unified view to slow-response catchments, where the priority shifts from warning speed to multi-day resourcing and evacuation planning.
"We had good gauges, good radar and a good forecast model. What we didn't have was one screen where a duty officer could see all three line up against a catchment's actual response time, so the four hours were mostly spent doing arithmetic in someone's head under pressure. Now the arithmetic is done before the shift starts, and the officer's judgement goes into the decision it should - whether to warn - not the maths behind it."
Working on something similar?
If this engagement looks like the kind of problem you are facing, we would be glad to compare notes by email.
Context and constraints
Flood warning has an unusual timing profile compared with most operational data problems: the underlying physical event - rain falling in an upstream catchment - is often observable hours before it becomes dangerous downstream, but the value of that lead time depends entirely on how much of it gets consumed by manually reconciling separate systems rather than acting on what they already show. The brief was explicit that the platform had to sit across the agency's existing gauge network, radar feed and hydrological model rather than replace any of them, since each had been independently validated over years of operation and the problem was in how they were viewed together, not in the underlying data sources themselves.
Public safety authorisation requirements shaped the build as much as the data problem did. A warning that reached households too early, based on a prediction that didn't materialise, would erode trust in every warning that followed it - a well-documented failure mode in flood response globally. The platform was built to surface a predicted breach window with a stated confidence range rather than a single number presented as certain, and to require a duty officer's explicit sign-off before any warning left the system, regardless of how confident the underlying prediction was.
Making the predicted breach window trustworthy enough to act on
The harder design problem wasn't pulling gauge, radar and forecast data into one screen - each already existed as a live feed - it was combining them into a breach-window prediction duty officers would actually trust enough to act on before the breach happened rather than after. We worked with hydrologists and duty officers together to encode each catchment's specific response-time characteristics - how quickly upstream rainfall historically translated into downstream level rise for that particular geography - rather than applying one generic response curve across catchments with very different terrain, soil saturation and river gradient profiles.
A full wet season before removing the fallback
We ran the platform in shadow mode alongside the existing three-screen process for an entire wet-season cycle before it became the primary tool, deliberately comparing its predicted breach windows against what duty officers using the old process actually decided, and against what the rivers actually did. That extended shadow period, rather than a shorter uptime test, is what surfaced a specific and consequential gap: one catchment's response-time assumption in the existing forecast model had not been updated to reflect recent land-use change upstream, meaning the model was systematically under-predicting how quickly that particular catchment would respond to heavy rainfall. A shorter pilot measured in weeks rather than a full season would likely have missed that gap entirely, since it only became visible against a specific combination of rainfall pattern and catchment condition that didn't recur every month.
Lessons learned
The first lesson was that a genuinely time-critical public safety decision - one where the underlying data already exists but is split across systems built at different times for different purposes - calls for a unified view with a human authorisation step built in, not a fully automated trigger, because the cost of a false public warning is not symmetrical with the cost of a few minutes' additional review time.
The second lesson was that a breach-window prediction is only as trustworthy as the catchment-specific response model behind it, and that model needs the same ongoing hydrological review as any other safety-critical input - a lesson the shadow-season comparison delivered directly by catching an out-of-date assumption before it caused a missed or late warning in a live event.
The third lesson was that running a full seasonal cycle in shadow mode, rather than a shorter uptime pilot, is what it took to build genuine confidence in a system whose failure mode - a missed or late flood warning - only shows up under specific, infrequent conditions rather than during routine operation.
If your organisation manages a time-critical public safety decision currently split across systems built at different times, we would be glad to discuss what a programme like this might look like for you. Email sales@halfteck.com.