AASRA

Project Overview

Pakistan has disaster-management institutions, volunteers, NGOs, and active community networks, but the project team identified a major software gap: there was no single integrated coordination platform connecting affected people, field volunteers, administrators, report prioritization, and aid visibility in one shared workflow.

AASRA — AI-powered Aid System for Rapid Assistance — was built as a working MVP to demonstrate how such a platform could operate for government and relief authorities. Instead of relying on disconnected calls, social-media posts, spreadsheets, and manual follow-up, the system turns a request for help into a structured case that can be reviewed, prioritized, assigned, tracked, and closed.

The goal was to make the concept tangible enough for government stakeholders to evaluate and improve through a formal pilot, not to present a student project as nationally deployable infrastructure.

At a Glance

• ▹
  Business goal: Demonstrate a practical model for coordinated digital disaster response in Pakistan.
• ▹
  Primary users: Disaster victims, volunteers and field responders, administrators, and relief coordinators.
• ▹
  Core solution: An Android application, web command dashboard, AI processing service, and shared cloud data layer.
• ▹
  Key outcome: A functional end-to-end MVP that connected emergency reporting, AI-assisted triage, volunteer task handling, administrative oversight, and donation visibility.

Market-gap note: This gap reflects the team's project research; it is not a verified inventory of every internal or private system in Pakistan.

Public-Sector Context

During floods, earthquakes, and other emergencies, requests for help often arrive through calls, social media, messaging applications, local volunteers, and physical aid points. These channels can spread information quickly, but they do not create a shared operational record. Administrators still need to verify the request, judge urgency, identify the location, coordinate a responder, and track whether the case was resolved.

AASRA was therefore framed as a government-facing demonstration MVP, not as another standalone SOS application. Its purpose was to show how victims, volunteers, administrators, and supporting organizations could work from the same case data.

The Challenge

The underlying problem was not a lack of people willing to help. Pakistan already has government agencies, NGOs, local communities, and volunteer networks involved in disaster relief. The missing layer was a shared digital process that could connect their actions.

What Was Not Working

• ▹
  Emergency requests were fragmented across calls, social media, messaging applications, and physical reporting points.
• ▹
  Administrators had to inspect and prioritize incoming information manually.
• ▹
  Volunteers could act without knowing whether another responder had already accepted the same case.
• ▹
  Victims had limited visibility into whether their request had been received or assigned.
• ▹
  Suspicious, repeated, or low-quality reports could distract attention from genuine emergencies.
• ▹
  Donation and resource information was difficult to present through the same operational view.

Why It Mattered

In a disaster, fragmented information creates operational risk. A critical case can be buried under less urgent messages. Two volunteers may travel to the same location while another area receives no response. Administrators may have no synchronized picture of the situation, and the public may lose trust when the status of requests and resources is unclear.

Without a working prototype, public-sector discussions about digitization remain abstract. AASRA gave decision-makers something concrete to review: a report lifecycle, distinct user roles, a command dashboard, and AI-supported decision assistance.

Project Goals

1. ▹
   Convert informal requests for help into structured, location-aware incident reports.
2. ▹
   Give volunteers a clear task workflow from discovery or assignment to resolution.
3. ▹
   Give administrators a centralized view for monitoring, filtering, assigning, and exporting reports.
4. ▹
   Use AI as decision support for urgency classification and suspicious-report awareness.
5. ▹
   Demonstrate a transparent, extendable foundation suitable for a government or institutional pilot.

The Approach

1. Mapping the Response Workflow

The team began by treating disaster response as a coordination problem rather than a feature list. The central question was: What must happen between a person asking for help and a responder closing the case?

This produced a clear workflow:

1. ▹
   A victim submits an SOS report with category, description, and location.
2. ▹
   The report is stored as a shared cloud record.
3. ▹
   The AI service adds an urgency level and anomaly indicator.
4. ▹
   Administrators review the updated report and coordinate action.
5. ▹
   A volunteer accepts the task or receives an assignment.
6. ▹
   The volunteer completes the response and updates the case.
7. ▹
   The final status becomes visible across the system.

This report lifecycle became the main product model. The report was not treated as a message; it was treated as an operational object with status, ownership, location, priority, and history.

2. Defining a Realistic MVP

The original concept included several ambitious features, including CNN-based image verification, a complete emergency chatbot, a fully interactive web map, and automated volunteer dispatch based on proximity and skills.

The team reduced the first release to the functions required to demonstrate one complete response loop. The MVP focused on:

• ▹
  role-based access;
• ▹
  structured SOS reporting;
• ▹
  mobile geospatial visibility;
• ▹
  volunteer task acceptance and resolution;
• ▹
  administrative monitoring and manual assignment;
• ▹
  AI-assisted text triage;
• ▹
  anomaly detection; and
• ▹
  donation and resource visibility.

The deferred features were documented as future work rather than being presented as completed capabilities. This kept the project credible and made the implemented workflow easier to validate.

3. Separating Interfaces by User Role

A single interface would have forced victims, volunteers, and administrators through the same navigation and information density. That would have been especially unsuitable for victims using the system under stress.

The solution was split into role-appropriate environments:

• ▹
  Android application: A field-facing interface for victims and volunteers. Victims can submit reports, while volunteers can view incidents, use location information, accept tasks, and mark them as resolved.
• ▹
  Web dashboard: A control surface for administrators who need broader visibility, filters, assignment controls, analytics, exports, and donation information.
• ▹
  AI service: A separate backend process that enriches reports without placing machine-learning logic inside the mobile or web interfaces.
• ▹
  Shared cloud layer: A common source of truth for identity, reports, statuses, assignments, priority values, and anomaly flags.

4. Designing AI as Assistance, Not Authority

The project did not have a large, locally labeled disaster-report dataset, so a custom accuracy claim would have been difficult to justify. The team used a pragmatic approach:

• ▹
  A zero-shot text-classification pipeline assigned High, Medium, or Low urgency labels.
• ▹
  An Isolation Forest model looked for unusual reporting patterns using behavioral signals such as report frequency, description length, and timing variance.
• ▹
  The output was treated as decision support for administrators, not as a final replacement for human judgment.

This demonstrated how AI could reduce manual sorting while keeping responsibility with authorized responders.

5. Building and Validating the End-to-End Flow

Development followed a modular, iterative process. The Android app, dashboard, AI engine, and cloud layer were connected through shared Firestore records. Validation focused on whether:

• ▹
  a victim could submit a report;
• ▹
  the report appeared correctly in the database;
• ▹
  the AI service added priority and anomaly metadata;
• ▹
  administrators could view and manage the report;
• ▹
  volunteers could accept and resolve the task; and
• ▹
  status changes remained visible across the ecosystem.

Testing included functional checks, integration scenarios, interface walkthroughs, backend/API checks, and code review. Nationwide load testing and production certification were outside the MVP scope.

The Solution

AASRA created one connected workflow across four technical layers.

Key Capabilities

• ▹
  Structured emergency reporting: Victims can create SOS reports containing a category, description, timestamp, location, and optional media reference.
• ▹
  Geospatial incident awareness: Volunteers can view incident information through the Android map interface and use location data to support field response.
• ▹
  AI-assisted triage: Report text is categorized by urgency so administrators can identify cases that may require faster attention.
• ▹
  Suspicious-report awareness: Behavioral anomaly detection flags unusual activity for administrative review.
• ▹
  Volunteer task management: Volunteers can accept active cases, navigate toward the incident, and update tasks to resolved.
• ▹
  Administrative command dashboard: Administrators can monitor reports, filter records, review status and priority, assign volunteers, and export information to CSV or PDF.
• ▹
  Donation and resource visibility: The dashboard provides an administrative view of donation-related data to support transparency.
• ▹
  Shared operational state: Firebase Authentication and Cloud Firestore keep role access and report data synchronized across mobile, web, and AI components.

Demonstrated Workflow Change

Key Results

Because AASRA was an academic MVP rather than a live government deployment, the project does not claim reductions in national response time, real-world lives saved, user adoption, or production-scale performance. Its results are best understood as validated product and workflow outcomes.

Product Outcomes

• ▹
  Established a working platform for three primary roles: victim, volunteer, and administrator.
• ▹
  Connected four major subsystems: Android application, web dashboard, AI processing service, and Firebase cloud layer.
• ▹
  Operationalized a complete incident lifecycle with pending, accepted, resolved, and rejected paths.
• ▹
  Demonstrated AI-assisted urgency classification and behavioral anomaly flagging within the same report record.
• ▹
  Connected volunteer actions and administrative monitoring to live shared data.
• ▹
  Included reporting exports and donation visibility to support oversight and accountability.

Technical Outcomes

• ▹
  Integration: Report creation, AI enrichment, dashboard monitoring, and volunteer status updates worked as one end-to-end flow in tested scenarios.
• ▹
  Maintainability: Mobile, web, AI, and cloud responsibilities were separated, allowing each subsystem to be improved independently.
• ▹
  Scalability direction: The modular architecture and cloud data layer provide a reasonable foundation for future growth, although disaster-scale traffic was not tested.
• ▹
  Scope discipline: Features that could not be fully verified were kept out of the completed MVP claim and moved into the roadmap.

Validation Limits

• ▹
  AI accuracy was not benchmarked against a large labeled Pakistani disaster dataset.
• ▹
  No national-scale concurrency, load, or stress testing was completed.
• ▹
  Automated end-to-end and UI test coverage was limited.
• ▹
  The product was not field-tested with government agencies, relief organizations, or affected communities.

These limits are important because the MVP was designed to support the next decision — whether and how to run an institutional pilot — rather than to present an academic build as production-ready public infrastructure.

Impact and Government Demonstration Value

AASRA turned a broad public-sector idea into a working system. A government department could use the MVP to evaluate questions that are difficult to answer from a written proposal alone:

• ▹
  Which information should be mandatory in an emergency report?
• ▹
  Which agency or role should verify, assign, reject, and close cases?
• ▹
  How should volunteers be registered and authorized?
• ▹
  Where should AI assist, and where must human approval remain mandatory?
• ▹
  Which integrations are needed with NDMA, PDMA, Rescue services, weather feeds, telecom providers, or local administrations?
• ▹
  What security, privacy, multilingual, offline, and audit requirements are necessary before field deployment?

The complete flow provides a starting point for requirements workshops, usability testing, security review, and a limited-area pilot before investment in nationwide infrastructure.

Technologies and Skills Demonstrated

Technology Stack

• ▹
  Mobile: Kotlin, Jetpack Compose, MVVM-style state management, Android location services
• ▹
  Web: React, Vite, Chart.js, jsPDF, PapaParse
• ▹
  Backend and AI: Python, FastAPI, Hugging Face Transformers, Scikit-learn Isolation Forest
• ▹
  Cloud and database: Firebase Authentication, Cloud Firestore
• ▹
  Maps: osmdroid and OpenStreetMap
• ▹
  Data and reporting: Google Sheets-based donation data, CSV and PDF export

Skills Demonstrated

• ▹
  Disaster-response workflow analysis
• ▹
  MVP scoping and roadmap control
• ▹
  Multi-role product design
• ▹
  Mobile, web, backend, and cloud integration
• ▹
  AI-assisted decision-support design
• ▹
  Geospatial application development
• ▹
  Functional and integration testing
• ▹
  Technical documentation and system modeling

My Role and Contribution

I worked as part of a three-person BSCS project team under academic supervision. The documentation records the work collectively and does not separate ownership by module, so this case study describes my contribution at team level.

The team was responsible for:

• ▹
  researching the disaster-coordination problem in Pakistan;
• ▹
  defining user roles, requirements, and the MVP scope;
• ▹
  designing the modular system architecture;
• ▹
  building and integrating the Android app, web dashboard, AI service, and cloud layer;
• ▹
  validating the report lifecycle through functional and integration scenarios; and
• ▹
  producing the technical documentation, diagrams, evaluation, and future roadmap.

Team setup: Three student developers, supervised by Sahar Moin at Lahore Garrison University.

Lessons and Reflection

• ▹
  What worked well: Designing around one shared report lifecycle gave every subsystem a clear purpose and kept the project focused on coordination rather than isolated features.
• ▹
  What I would improve: The next version should begin with government and field-worker interviews, clearer individual ownership, test automation, security threat modeling, and a controlled field pilot.
• ▹
  What the project taught me: In public-safety software, a credible MVP is not the version with the longest feature list. It is the smallest version that demonstrates a complete operational process while clearly separating what works today from what still requires validation.

Recommended Next Phase

To move from academic MVP to institutional pilot, the next phase should include:

1. ▹
   Requirements workshops with NDMA, PDMA, Rescue services, NGOs, and volunteer organizations.
2. ▹
   A limited geographic pilot with clear operators, escalation rules, and response responsibilities.
3. ▹
   Urdu and regional-language support, accessibility testing, and low-connectivity workflows.
4. ▹
   Stronger identity verification, audit logs, privacy controls, automated tests, load testing, and production monitoring.
5. ▹
   Local AI evaluation and verified integrations with weather, flood, mapping, emergency-service, and volunteer-dispatch systems.

Closing Summary

AASRA was created to demonstrate how Pakistan could move from fragmented disaster communication toward a coordinated digital response workflow. The MVP connected victims, volunteers, administrators, AI-assisted triage, shared case status, and donation visibility in one system.

It is not presented as a finished national platform. Its value is that it gives government and humanitarian stakeholders a concrete foundation for discussion, testing, and pilot planning.

Project takeaway: Built a working multi-platform MVP that demonstrated how a unified government-facing disaster coordination system for Pakistan could capture, prioritize, assign, monitor, and close emergency cases.