AI Enterprise SolutionsGPT & Claude

Xabardar — AI-Assisted Emergency Response Platform

During earthquakes and other emergencies, response coordinators, social workers, and emergency operations teams face a critical challenge: they often cannot quickly determine which affected residents are safe, injured, or unable to respond. This problem is especially serious for elderly people, individuals living alone, and vulnerable residents. Manually checking on everyone takes time, while treating every case with equal priority can delay assistance to those who need it most. Xabardar addresses this information gap with an emergency response coordination platform. When an incident is registered, the system identifies consenting residents within the affected area and creates safety check-ins. Their responses are analyzed and classified into three priority levels: - RED — urgent assistance needed or no response. - AMBER — unclear situation requiring review. - GREEN — appears safe based on the response. Instead of manually reviewing every response, operators receive a prioritized dashboard showing which cases deserve attention first. The prototype supports Azerbaijani and English text classification, simulated voice check-ins, location-based incident management, and human-controlled escalation. Our goal is to help emergency response teams identify potentially vulnerable people faster, reduce manual coordination, and make better-informed decisions during critical situations. Xabardar is currently a functional prototype using synthetic data and simulated communications, not an operational emergency service.

Open the demo GitHub

Preliminary score

58.5/ 100Promisingaverage of 2 judges

Value for the user18.0 / 25
A specific problem and a clear outcome from solving it.
Prototype and use of AI12.5 / 30
A working core scenario, and what AI actually contributes to the result.
Quality testing14.0 / 20
Tests, examples of failures, and comparison with the current approach.
Feasibility9.0 / 15
Data requirements, running costs and a clear next step.
Originality5.0 / 10
A meaningful difference from common solutions.

What the judges wrote

Claude Opus 5.5Preliminary55/100
Strengths
Your problem framing is concrete: during an earthquake, coordinators need to know quickly which consenting, vulnerable residents are safe, hurt or silent. Rules such as 'silence is red' and 'unrecognised text is amber, never green' are thoughtful safety defaults. You built a real FastAPI/SQLite backend with role-based auth, consent handling, an audit log, human-approved 112 escalation and live priority streaming, covered by 33 automated tests. Your testing write-up stands out for honesty: a 60-case confusion-matrix evaluation, specific fixed failures ('ok' matching 'okul', chest pain landing in amber), and a clear statement that the set is not independent.
To improve
The runtime classifier is deterministic keyword rules, so AI does not yet contribute to the result. That is the main weakness for this criterion; replacing or backing up the rules with a language model or a trained Azerbaijani classifier, and comparing red recall against your rule baseline, would change that. Name and estimate the adoption metric the track asks for, such as time-to-identify all RED cases versus manual phone trees, and compare against how coordinators work today. Add running-cost estimates for telephony, ASR and hosting at pilot scale. Fill in the demo password in your setup notes so judges can actually sign in.
GPT-6 AstraPreliminary62/100
Strengths
Your project addresses a concrete coordination problem for emergency operators, with a documented workflow connecting consent, geographic filtering, response classification and human-controlled escalation. Your testing identifies specific failures—including substring matching and missed urgent phrases—and describes corresponding fixes. Your clear distinction between simulated functionality, developer regression results and real-world safety is particularly valuable in this domain.
To improve
Your next evaluation should use independently labelled, held-out responses and compare against manual triage, measuring urgent-case recall, false alarms and operator time saved. Your runtime classifier is deterministic; demonstrate whether an AI component adds measurable value beyond these rules while retaining human oversight. Your feasibility case needs estimated communication and hosting costs for a narrowly scoped supervised pilot. Replace the demo-password placeholder and consolidate outdated README sections so the current workflow and test coverage are reproducible.

The team

Gutsi Naghiyev
developer
Ravana Guliyeva
business
Narmin MammadovaLead
product
Rahim Farzaliyev
developer

Disclosure

Required by the rules. Judges verify it against the repository.

Models: ChatGPT (OpenAI) and Claude (Anthropic) were used as AI-assisted development tools for code generation, debugging, software design, testing, and documentation. The current runtime emergency-response classifier uses deterministic multilingual keyword and safety rules. No hosted large language model is integrated into the live classification pipeline. The prototype does not claim to provide independently validated AI emergency diagnosis.
Data: Synthetic resident profiles, simulated emergency events, and 60 developer-labelled Azerbaijani and English emergency-response examples. SQLite is used for prototype data storage. The demonstration does not use real patient records, private health datasets, or live emergency-service information. All simulated resident and incident data was created for development and testing purposes.
Components: Python, FastAPI, SQLite, HTML, CSS, JavaScript, Uvicorn, browser speech synthesis, GitHub, GitHub Actions, and Render hosting. Custom prototype components include authentication, geographic incident filtering, resident management, multilingual rule-based classification, priority ranking, simulated call retries, escalation queues, motorcycle incident assessment, hazard monitoring, and operational metrics. ChatGPT and Claude supported the development workflow. No real telephony, SMS, emergency dispatch, or official earthquake-feed provider is connected.
Built during the event: Confirmed

Quality testing

QUALITY TESTING AND VALIDATION Xabardar was developed using an iterative testing approach focused on emergency-response reliability, authentication, prioritization, and the correctness of simulated workflows. AUTOMATED TESTING The latest local test run passed 33 out of 33 automated tests covering authentication, API access, event creation, geographic filtering, response classification, dashboard behavior, and simulated escalation workflows. CLASSIFIER EVALUATION A dataset of 60 developer-labelled Azerbaijani and English responses was used to evaluate emergency risk classification. After rule improvements, all 60 examples matched their expected classifications. The dataset includes emergency requests, reassurance phrases, unclear responses, and selected linguistic variations. However, these examples were also used during development, so the result is not an independent assessment of real-world emergency detection accuracy. FAILURES IDENTIFIED AND FIXED 1. Login interface: A CSS visibility issue caused the login form to remain visible after successful authentication. The visibility behavior was corrected. 2. Keyword matching: Short expressions such as "ok" could incorrectly match unrelated words such as "okul". Whole-word matching was implemented. 3. Missed risk phrases: Some urgent expressions, including chest pain and immediate assistance requests, were initially classified as unclear. Additional safety rules and regression examples were added. 4. Token handling: URL query-string authentication was disabled to reduce the risk of exposing access tokens. COMPARISON WITH THE INITIAL APPROACH The initial demonstration relied on browser-only simulated events and JavaScript-based response handling. The improved prototype includes a FastAPI backend, SQLite storage, authenticated API endpoints, event records, prioritized responses, and automated regression tests. CURRENT LIMITATIONS The evaluation dataset is small and development-labelled. Real calls, speech recognition, physical motorcycle sensors, live hazard feeds, and emergency dispatch are not integrated. Full independent field validation and real-user safety testing remain necessary before any operational use. NEXT VALIDATION MILESTONE Build an independently labelled Azerbaijani emergency-response dataset, measure red-class recall and false-alarm rates, evaluate speech-to-text performance, and conduct a supervised pilot with appropriate consent and human oversight.

Worth 20 of the 100 points.

Running it

XABARDAR — LIVE PROTOTYPE Live demo: https://xabardar-hackathon.onrender.com Source code: https://github.com/gutsi-366/xabardar-hackathon HOW TO USE 1. Open the live demo in a desktop browser. The free hosting instance may need up to a minute or longer to wake up. 2. Sign in using the provided demo administrator credentials. 3. Open the Emergency Response Dashboard. 4. Create an earthquake event or select an existing incident. 5. View affected residents and pending safety check-ins. 6. Open a simulated call and enter a response such as "Kömək lazımdır, yıxıldım" (I need help, I fell). 7. Observe how the response is classified and the priority queue is updated. 8. Explore the simulated notifications, motorcycle incident assessment, hazard monitoring, and operational metrics. DEMO CREDENTIALS Username: admin Password: [INSERT YOUR WORKING DEMO-ONLY PASSWORD] LOCAL SETUP Clone the GitHub repository and open the project directory. Install dependencies: pip install -r requirements.txt Set XABARDAR_ADMIN_PASSWORD to a unique password of at least 10 characters. For a new database only, initialize the demo: python -m app.seed --demo Start the server: python -m uvicorn app.main:app --host 127.0.0.1 --port 8081 Open: http://127.0.0.1:8081 KNOWN LIMITATIONS The application uses synthetic resident data. Phone calls, SMS, emergency dispatch, motorcycle sensors, and hazard feeds are simulated. No real emergency services are contacted. The demonstration uses SQLite and is not designed for production deployment.

Project ownership

The team keeps the rights to this project. Judges were given access for verification only.