Building TerraPulse AI: From Hyderabad’s Urban Flooding to Graph-Based Environmental Resilience
How I built TerraPulse AI using the AWS Strands Agents SDK, FalkorDB and environmental data to explore interconnected risks from flooding, extreme heat, water scarcity and infrastructure leaks in Hyderabad.
Building TerraPulse AI: From Hyderabad’s Urban Flooding to Graph-Based Environmental Resilience
When heavy rain hits a city, the problem rarely ends with water on the road.
A road becomes difficult to cross. A hospital may become harder to reach. A repair crew may struggle to access a damaged water pipeline. Meanwhile, another part of the city might be dealing with extreme heat or pressure on its water supply.
Living in Hyderabad, Telangana, these are the kinds of interconnected urban problems that made me think beyond a conventional environmental dashboard.
For the Environmental Hacks hackathon, I started building TerraPulse AI, an environmental resilience platform designed to help city teams explore environmental risks, compare possible interventions, and understand how one disruption can affect other parts of the city.
The goal was not simply to display weather information on a map. I wanted to explore a more practical question:
Given the information available, what could a city team investigate or prioritise next?
The research idea that influenced my thinking
One paper that helped frame the problem was Evelyn Mühlhofer, David N. Bresch and Elco E. Koks’ 2024 study, “Infrastructure failure cascades quintuple risk of storm and flood-induced service disruptions across the globe,” published in One Earth.
The authors studied more than 700 historical flood and tropical cyclone events across 30 countries and regions. Their work examined how infrastructure dependencies can cause service disruptions to extend beyond the areas directly affected by a hazard.
The insight I took from this research was that assessing individual damaged assets is not always enough; we also need to consider the services and connections that depend on them.
A road is not just a line on a map. Its availability can affect access to healthcare and the movement of repair crews. A disruption in one location can influence decisions elsewhere.
This paper did not provide a ready-made implementation for TerraPulse, and my project does not reproduce or validate the authors’ findings. Instead, it helped motivate the systems-level question I wanted to explore.
What TerraPulse AI does
TerraPulse brings four environmental problem areas into one decision-support interface.
1. Flooding and hospital accessibility
The flood module models potential road disruptions under selected rainfall scenarios. It allows users to compare hypothetical pump placements and examine how those interventions could change road accessibility.
Hospital access is an important part of this analysis. Rather than looking only at which neighbourhoods might be affected, TerraPulse can examine how simulated road closures influence routes to hospitals.
The system also compares intervention strategies and explores how flood-related road closures could affect infrastructure repair work.
These are modelled scenarios, not operational flood forecasts. The current model has important limitations and has not demonstrated reliable predictive skill against the available local reports.
2. Extreme heat
The heat module explores candidate cooling-shelter locations and compares their modelled coverage of neighbourhoods.
The idea is to move beyond showing a temperature value and investigate how the placement of a hypothetical intervention could change coverage.
The current analysis does not establish real shelter capacity, staffing, population vulnerability or guaranteed access.
3. Water scarcity
The water module examines rainfall deficits and uses explicit assumptions to explore possible water-supply stress and tanker allocation.
This distinction matters: a rainfall deficit is not direct evidence that a particular neighbourhood is experiencing a municipal supply shortage. TerraPulse treats the supply impact as a scenario to investigate, not a confirmed measurement of the city's water distribution system.
4. Water leaks and repair prioritisation
The leak module explores how repair priorities might change when roads become inaccessible or when infrastructure work depends on other routes being available.
The current leak incidents are synthetic, rather than confirmed reports from live municipal sensors. The module is intended to demonstrate the decision-support workflow, not claim that TerraPulse has detected actual pipeline leaks.
Residents can also view available conditions and official warnings, and submit local reports. These reports are not automatically verified or sent to emergency services.
Why I chose a graph database
Many urban systems are naturally interconnected.
Roads connect intersections. Hospitals depend on accessible routes. Repair crews need to travel through the same network affected by a disruption.
Representing these relationships as a graph makes it possible to ask questions that are harder to express through isolated charts.
TerraPulse uses FalkorDB to represent the city’s road network and related infrastructure. Graph pathfinding supports tasks such as examining hospital accessibility and evaluating travel routes under simulated closures.
For example, instead of merely displaying a road closure, the application can investigate whether an alternative route remains available and how a set of hypothetical interventions changes connectivity.
This does not mean the graph contains a complete digital representation of Hyderabad. Its results are constrained by the infrastructure data available, the model assumptions and the geographic coverage represented in the application.
Using the AWS Strands Agents SDK
I integrated the AWS Strands Agents SDK, an open-source framework for building agents that use tools.
TerraPulse registers 22 typed tools across its environmental analysis workflows. Examples include:
-
trace_cascading_impacts
-
compare_scenarios
-
evaluate_route_access
-
query_city_graph
-
trace_flood_repair_dependency
-
run_flood_network
-
get_official_alerts
These tools connect the application’s workflows to the underlying analysis engine and, where needed, the FalkorDB graph.
An important implementation detail is that the current setup invokes the Strands tools without calling an AI model. The analysis is deterministic under the same inputs and configuration, making the tool execution easier to reproduce and inspect.
I wanted the application to expose the steps behind a result rather than simply return a recommendation with no explanation of how it was produced.
Strands provides the tool-orchestration framework here; it does not independently validate the environmental models or make their assumptions scientifically correct.
The application currently runs locally. It does not use Amazon Bedrock or AWS cloud hosting, so I am not claiming a cloud deployment or managed AWS infrastructure integration.
The data and engineering challenges
Combining multiple data sources into one interface introduced its own challenges.
TerraPulse uses sources and infrastructure data that include Open-Meteo, NDMA SACHET, OpenStreetMap, Copernicus elevation data and Groundsource reports. Each source has a different purpose, coverage and level of certainty.
Some data represents forecasts or model estimates. Some describes mapped infrastructure. Some consists of reports, and some of the scenarios and incidents are synthetic.
Treating all of these as equally reliable would create a misleading impression of precision. I therefore focused on distinguishing observed or reported information from modelled outcomes and hypothetical interventions.
Another challenge was the gap between a convincing visualisation and a useful analytical result. A map can look persuasive even when the model behind it has limited predictive ability.
For example, the current flood-risk model has not demonstrated useful predictive skill against the available Groundsource-reported areas. That is a significant limitation, not a result I want to hide behind a polished dashboard.
Other limitations include incomplete local drainage and hydrological modelling, simplified assumptions about intervention effects, and incomplete information about actual hospital operating status and shelter capacity.
These issues define the next stage of work: better local validation, stronger physical modelling, improved exposure data and more realistic intervention assumptions.
What I learned
Building TerraPulse reinforced three lessons for me.
First, infrastructure relationships matter. Understanding a hazard is only part of the problem; understanding how it may affect access and other services can be just as important.
Second, reproducibility is useful, but it is not the same as accuracy. Deterministic tools make results easier to trace and repeat. They do not remove uncertainty in the data or assumptions.
Third, environmental decision support needs honest limitations. A useful prototype should help people explore possible actions while making clear which conclusions are supported by data and which depend on simulation assumptions.
TerraPulse is an early engineering prototype, not a validated municipal emergency-management system. Its purpose is to explore how environmental data, graph-based infrastructure analysis and structured tool execution can be brought together in one workflow.
What comes next
My next priorities are improving the validation of flood scenarios, documenting the assumptions behind interventions, expanding the quality of local infrastructure data and making the tool execution easier to audit.
I also want to investigate how the framework could support more rigorous evaluation of environmental interventions instead of relying only on visually compelling scenario comparisons.
For me, the most interesting question is not whether a dashboard can display a hazard. It is whether a decision-support system can help someone understand the consequences of possible actions, explain why it produced a result, and communicate what remains uncertain.
That is the direction I want to take TerraPulse AI.
Research reference: Mühlhofer, E., Bresch, D. N., & Koks, E. E. (2024). Infrastructure failure cascades quintuple risk of storm and flood-induced service disruptions across the globe. One Earth, 7(4), 714–729. https://doi.org/10.1016/j.oneear.2024.03.010
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article