AWS Builder Center

Builder Center

When Delhi's Roads Flood, Who Needs to Act?

When Delhi's Roads Flood, Who Needs to Act?

Building DisputePoint on AWS to help incident commanders review evidence, resolve disputed responsibility claims, and record decisions without manufacturing certainty.

When a road floods during Delhi’s monsoon, people lose time, vehicles can become stranded, and everyday journeys become difficult.
Coordinating a response can be complicated too. Different agencies may be responsible for different roads and drains, and sometimes the available information does not establish who should act.
In July 2025, the Delhi High Court highlighted coordination problems among civic agencies dealing with drainage and flooding. These proceedings provide context for the problem we wanted to explore with DisputePoint. They do not establish that every waterlogging incident is caused by an ownership dispute, and they do not endorse this product.
Read the Times of India report  · Read the LiveLaw report  · Read the Delhi High Court order dated 19 August 2025 
DisputePoint is a prototype for coordinating waterlogging incidents, reviewing responsibility claims, and recording decisions in one operational workflow.

The problem we wanted to solve

A map can show where an incident is reported. The response team still needs to answer a few practical questions:
  • Which incidents need attention first?
  • What evidence is available?
  • Which agency is responsible, if that can be established?
  • What should happen when responsibility claims conflict?
  • How should the decision and its rationale be recorded?
We focused on this coordination problem rather than building another citywide flood visualization. DisputePoint is not a flood heatmap, a citizen complaint inbox, or a flood predictor.
The prototype is designed for an incident commander or coordination officer who needs to review incidents, understand responsibility claims, and coordinate the next action.

What we built

DisputePoint brings an incident queue, a map, an evidence view, and a responsibility workflow into one interface.
The workflow is:
INCIDENT → PRIORITY → CLAIMS → EVIDENCE → DECISION → ACTION → AUDIT
The application distinguishes three ownership states:
  • ASSIGNED: responsibility is assigned to an agency.
  • CONFLICT: competing claims remain unresolved.
  • UNKNOWN: available evidence does not establish responsibility.
These states affect what the system is allowed to do next.

Why DisputePoint does not guess under conflict

One design decision shaped the rest of the project: when evidence supports competing responsibility claims, the system must not automatically select an agency.
In our ownership model, CONFLICT means the responsible agency remains unset:
responsible_agency = null
The incident can still be prioritized. The available evidence can still be reviewed. An officer can still take the next step. What the system cannot do is pretend the disagreement has already been resolved.
For example, open Okhla or Samaypur Badli in the demo. Responsibility remains disputed while the competing claims and available source material stay visible.
An authorized officer must review the evidence before confirming responsibility. Disputed cases follow the appropriate review and escalation path rather than being automatically assigned. The decision and its rationale are recorded in the audit trail.
This is important because a dashboard can look complete while hiding uncertainty. We wanted the unresolved state to remain visible until an authorized human decision is recorded.
The system does not use an AI-generated answer to silently resolve conflicting ownership claims.
One of the harder parts was keeping the interface honest about system state. A source being unavailable is not the same as evidence being verified, and a disputed responsibility claim cannot safely become an assignment just because the interface needs an answer. We had to treat these distinctions as application rules rather than presentation details. That changed how we represented evidence, handled conflicting claims, and recorded human decisions.

Keeping priority separate from responsibility

Rainfall matters to waterlogging response, but it answers a different question from asset ownership.
Rainfall can affect how urgently an incident needs attention. It cannot, by itself, establish who maintains a drain or road.
DisputePoint treats priority and responsibility as separate decisions. Its rainfall scenario is intended to exercise the prioritization workflow, not to predict flooding or establish responsibility for an asset.
The queue ranking has not been validated against emergency-response outcomes. It is a prototype ranking for triage, not a certified urgency score.

Connecting evidence to decisions

The evidence view helps an officer examine what supports a claim and what remains missing. This includes the source, quotation, verification status, and relationship to the decision.
A source existing is not the same as a claim being verified. A quotation being accurately extracted is not the same as that quotation establishing jurisdiction over a particular asset. Even a court quotation may require human review of its context and legal meaning before it can be treated as settling ownership.
The current prototype contains a 35-location Delhi incident corpus and supporting evidence fixtures. This demonstrates the workflow, but it is not a comprehensive or independently verified account of every incident or agency responsibility in Delhi.

Deploying the prototype on AWS

We deployed the DisputePoint frontend as a static web application on Amazon S3 and exposed the backend through API Gateway and AWS Lambda.
DynamoDB stores invoke stamps and workflow-related audit records. S3 also holds the private evidence and runtime snapshot used on cold start. EventBridge schedules rainfall refreshes every 15 minutes and evidence-verification batches hourly. CloudWatch receives Lambda logs for the decision function.
We chose this serverless architecture to build and deploy the prototype without managing a fleet of application servers. The deployment demonstrates the application's workflow, but it does not establish production readiness for a citywide emergency-management system.
You can explore the project here:

Three lessons from building DisputePoint

1. Sometimes the correct answer is "not established yet"

When the evidence is inconclusive, forcing an assignment can hide the most important fact about an incident.
Leaving responsibility unresolved is more honest than presenting an unsupported answer as settled.

2. Related signals should not become interchangeable

Rainfall, priority, evidence quality, and responsibility all matter, but each answers a different question.
Keeping them separate makes the system easier to reason about and reduces the risk of one signal determining an unrelated decision.

3. Human decisions need enforceable rules

A human-in-the-loop label is not enough by itself. The backend must enforce who can make a decision, which state transitions are allowed, and what must be recorded.
The interface should make the workflow understandable, while the backend protects the rules that matter.

What remains to be proven

DisputePoint is a hackathon-stage prototype, not a validated citywide emergency-management system.
Its current corpus is limited in size and coverage. The application does not establish live flood depth, provide a validated flood-prediction model, or prove that its queue improves real-world response times.
The next step would be a ward-level pilot with relevant response teams and verified asset and jurisdiction records.
We would measure:
  • Time from incident intake to a documented responsibility decision.
  • Time from responsibility confirmation to an acknowledged action.
  • The proportion of disputed incidents resolved with documented evidence.
  • The proportion of incidents that remain unresolved because required evidence is missing.
These are proposed evaluation metrics, not results demonstrated by the current prototype.
We still need to test whether making incident priority, responsibility, and evidence easier to inspect helps response teams coordinate their work more effectively.

Try the prototype

Explore the live DisputePoint application , inspect the AWS architecture , or browse the source repository .
Tools and credits: Rainfall observations use Open-Meteo, licensed under CC BY 4.0. Third-party quotation notes and attribution details are maintained in the project repository.
For other builders: How would you model conflicting responsibility claims in an operational workflow? Would you use explicit ownership states, an evidence graph, or another approach?
I'd be interested in how others would handle the boundary between automated prioritization and a decision that must remain with an authorized human.
# hackathon# serverless# amazon-dynamodb# aws-cli# multi-cloud
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article