HackStack

Project Info

Lifeline AI

Devpost

This project did not submit a demo video on Devpost.

Inspiration

Lifeline AI was inspired by a simple but urgent problem: during disasters, the people who need help the most are often hidden inside scattered information. Emergency alerts, news updates, social media posts, community reports, and voice calls all contain valuable signals, but they are usually fragmented and difficult to process quickly. In a crisis, every minute matters. A post saying “need oxygen,” a call saying “my grandmother is trapped,” and an alert about rising floodwater may all point to the same high-risk situation. We wanted to build a system that could help responders connect those dots faster. Our goal was to create an AI-powered emergency intelligence platform that helps emergency teams, hospitals, shelters, NGOs, and local communities understand where help is needed most urgently. What Lifeline AI Does Lifeline AI collects crisis signals from multiple sources and transforms them into structured emergency incidents. The system can take information from alerts, web sources, community posts, and voice reports, then organize it into a clear response workflow. The core idea is: fragmented crisis signals → structured incidents → related incident clusters → priority scores → actionable recommendations Instead of showing responders hundreds of disconnected reports, Lifeline AI groups related information and ranks incidents by urgency. For example, if multiple reports mention flooding, a trapped person, and an oxygen need near the same location, the system can merge those signals into one high-priority incident cluster. How We Built It We built Lifeline AI as a multi-agent system with a backend, frontend dashboard, memory layer, and incident-processing pipeline. The backend was built using FastAPI. We created endpoints to process incoming crisis reports, retrieve incident clusters, and generate a priority queue. Each incoming report is converted into a structured incident with fields such as event type, location, urgency, medical need, confidence, and source. We designed the system around several key components: Data ingestion agents for collecting crisis signals from alerts, web reports, social/community inputs, and voice calls using browserbase and deepgram APIs ASI:One / orchestration logic to coordinate the workflow and reason over incoming reports. Incident extraction to convert raw text into structured emergency data. Incident fusion logic to decide whether multiple reports refer to the same event. Redis memory to store incident clusters and retrieve past context. Priority scoring to rank incidents based on urgency, medical need, vulnerability, and repeated confirmation. Responder dashboard to show the most urgent incidents and recommended actions. The fusion logic checks multiple signals before merging reports: [ \text{Fusion Score} = w_1(\text{semantic similarity}) + w_2(\text{location distance}) + w_3(\text{time closeness}) + w_4(\text{event type match}) ] This helped us represent the real-world idea that two reports should only be merged if they are similar in meaning, close in location, close in time, and describe the same type of emergency. What We Learned We learned that the most important part of disaster AI is not just collecting information, but making it usable. A dashboard full of raw reports can still overwhelm responders. The real value comes from clustering, prioritization, and clear recommendations. We also learned how important reliability and explainability are in emergency systems. A system like this cannot simply output an answer; it must show why an incident was prioritized. For that reason, we focused on making the priority score understandable through factors like medical need, trapped people, rising water, and multiple related reports. Another key learning was that building with multiple agents requires clean data structures. Once we created a shared incident schema, it became much easier to connect different parts of the system together. Challenges We Faced One of the biggest challenges was deciding the right scope for a hackathon. Disaster response is a large and complex problem, so we focused on building a working slice of the system: report intake, incident extraction, clustering, priority scoring, Redis memory, and a dashboard. We also faced technical challenges connecting the backend, frontend, and Redis memory layer. Import paths, package setup, and local development issues took time to debug. Another challenge was designing the fusion logic in a way that was simple enough to implement quickly but still meaningful enough to demonstrate real impact. A major product challenge was keeping the system understandable. We wanted judges and users to immediately understand what Lifeline AI does, so we simplified the demo around one clear story: scattered crisis reports enter the system, Lifeline AI organizes them, and responders receive a prioritized action plan. Impact Lifeline AI can help several groups during disasters: Emergency responders can identify urgent rescue and medical cases faster. Emergency operations centers can use it as a live intelligence dashboard. NGOs and shelters can understand where supplies and support are needed. Hospitals and medical teams can detect urgent needs like oxygen, insulin, dialysis, or elderly care. Local communities can report emergencies through accessible text or voice inputs. By reducing confusion, grouping duplicate reports, and prioritizing urgent cases, Lifeline AI can help responders allocate limited resources more effectively. Conclusion Lifeline AI is our attempt to use AI for a real human problem: helping people get support faster when disasters strike. We built it as a multi-agent emergency intelligence platform that turns fragmented crisis information into structured incidents, clustered reports, priority scores, and actionable recommendations.

Analysis

Compare with all teams

View

Metric

No commits on this project resolved to a GitHub account.

Technology

Found in codeClaimed only
  • CSSIn code
  • FastAPIIn code
  • Next.jsIn code
  • PythonIn code
  • ReactIn code
  • Tailwind CSSIn code
  • TypeScriptIn code
  • JavaScriptClaimed
  • RedisClaimed

7 of 9 appear in the indexed code. 2 claimed on Devpost could not be matched to code, which may simply mean the tool leaves no trace in the repository.

AI coding agents

  • Claude CodeConfig
  • CodexConfig

Detected from committed agent config files and commit authorship. Absence of a signal is not proof an agent was unused.

Codebase size

Source size

83 KB

Source files

50

Counts recognized source files only; vendored directories, binaries and lockfiles are excluded, so this is smaller than the repository on disk.

0 stars