Lifeline

Inspiration

Lifeline stemmed from a worrying observation: even in cities filled with cameras, emergency response depends entirely on someone noticing and dialing 911. In situations where someone is unconscious and alone, that assumption breaks down. Turing City gave us the perfect framing. If AGI is integrated into infrastructure, public safety would be one of the first areas where it shows real value.

What it does

Lifeline automatically detects and processes high-severity emergencies using live security cameras.

When a potential emergency occurs:

• Every second, a recent video frame is analyzed
• The software first determines whether a human is in the frame
• If the software detects a human, we determine if the situation is informational or an emergency
• An AI-generated title and description summarize what's happening
• The nearest available ambulance is identified and dispatched, either automatically or after human approval

All of this is visualized in a live dashboard showing cameras, events, ambulances, ETAs, and system statistics.

How we built it

We designed Lifeline as a modular, end-to-end system.

Camera Analysis Pipeline: A lightweight vision model, YOLOv26, first checks whether a person is present. Only then do we run a heavier vision-language model, Qwen3-Instruct, on short video clips to produce structured event data.

Backend: A FastAPI server handles event processing, ambulance assignment, routing, and statistics aggregation. The data is stored using document-based models to ensure the project state is easy to develop.

Frontend: A React/Vue dashboard renders a city map with live icons for emergencies, cameras, and ambulances. Clicking any of these objects opens a detailed side drawer with context, status, history, and an emergency button that triggers an emergency for that specific camera location.

Dispatch Logic: The system supports two modes:

• Human assisted approval
• Fully automated dispatch above a severity threshold

Challenges we ran into

Misinterpreted vision: Not every person lying down is dead, and not everyone who trips is in danger. Designing a severity classification that was both cautious and useful took many clauses and careful thought.

Cost and Performance: Continuously running large models is expensive. We had to carefully gate inference to keep the system realistic. We chose to pass the live footage through YOLOv26 first and use Qwen3-Instruct instead of the flagship Qwen3, and in total, these considerations lowered costs by about ~80%.

State Consistency: Keeping events, ambulances, and UI views synchronized in near real time required clean data models and polling strategies.

AGI Trust: Deciding how much power to give AGI versus humans forced us to think carefully about failure modes, leading to many different ideas for human-safe-clause implementations.

Accomplishments that we're proud of

• Building a full emergency response loop
• Designing a clean event schema that works across two different AI models, our backend, and UI
• Supporting both automated and human-approved dispatch methods
• Creating a dashboard that stays readable even with many simultaneous events

What we learned

• In safety-critical systems, innovative structured outputs matter more than using chunky flashy AI models
• Multi-stage pipelines dramatically improve cost efficiency without sacrificing performance
• Clear system flow is just as important as model choice

What's next for Lifeline

• Better temporal reasoning to distinguish accidents from benign behavior, although Qwen is pretty good. Maybe an organic model trained just for these situations.
• Confidence scoring and uncertainty visualization for responders
• Real routing APIs instead of simulated paths
• Integrating additional signals beyond cameras

Our long-term goal is to make sure help arrives even when no one can ask for it.

Built With

• beanie
• fastapi
• javascript
• mongodb
• react
• typescript
• websockets