ResQmesh

overall workflow of the project

Inspiration

It started with a situation that many of us fear: someone close to you gets into an accident, and your immediate thought is to get help there as quickly as possible. But in a real emergency, the challenge is not simply finding an ambulance. Traffic, incomplete information, ambulance availability, hospital capacity, route feasibility, and uncertainty about the incident can all affect the response.

That made us ask a simple question: Can AI help emergency responders make faster and better informed decisions without giving an AI model unchecked control over critical decisions?

This question inspired us to build ResQMesh, pronounced RescueMesh, an AI assisted emergency response decision support system.

What it does

ResQMesh converts an unstructured emergency report into a structured and explainable response workflow.

Instead of sending the entire problem to an LLM through one large prompt, ResQMesh uses a controlled multi stage prompt engineering workflow.

The system first uses specialized prompts to extract incident information and identify ambiguity. If critical information is missing, the workflow stops and requests clarification from a human dispatcher rather than allowing the AI to guess.

The system then extracts priority cues before passing the problem to a deterministic response engine. This engine handles operational constraints such as ambulance availability, ambulance capability, hospital feasibility, and route calculation.

The proposed response is then challenged by an adversarial LLM reviewer and independently verified through deterministic checks. Only after verification does the system generate a dispatcher facing explanation.

The final response still requires human approval before execution.

The core principle behind ResQMesh is:

LLMs interpret and challenge. Deterministic systems enforce constraints. Humans retain authority.

How we built it

We designed ResQMesh as a combination of prompt engineering, deterministic algorithms, validation layers, and human in the loop decision points.

The backend is built with Python and FastAPI, with Pydantic used for structured validation and NetworkX for graph based processing. OpenStreetMap based geographic data is used for routing related processing.

The frontend is built using React and Vite, providing an interface for interacting with the emergency response workflow.

Our ML prompt engineering workflow consists of specialized prompts with clearly defined responsibilities:

incident_extractor_v1 Extracts evidence supported incident facts into a structured incident state. ambiguity_gate_v1 Detects missing or conflicting information that could affect the response. priority_cues_v1 Extracts evidence backed severity and priority cues. adversarial_reviewer_v1 Challenges the proposed response and searches for contradictions, unsafe assumptions, and constraint violations. explanation_generator_v1 Generates a concise explanation based only on the verified response.

The system deliberately separates AI interpretation from operational decision making. The LLM does not directly select an ambulance, calculate the route, or make the final dispatch decision.

Challenges we ran into

The biggest challenge was deciding where AI should be used and where it should not be trusted with operational authority.

It was relatively easy to make an LLM generate a complete emergency response. The difficult part was designing a workflow where that response could be challenged, verified, and safely passed through human approval.

We also had to deal with unstructured emergency information. Real world reports may contain incomplete descriptions, conflicting details, or ambiguous locations. Allowing those uncertainties to propagate through the system could result in an incorrect response.

We addressed this by introducing ambiguity gates, structured outputs, deterministic validation, adversarial review, and explicit human intervention points.

Another challenge was integrating multiple stages without turning the workflow into a simple chain of LLM calls. Each stage therefore has a specific responsibility and a clearly defined boundary.

Accomplishments that we're proud of

We are particularly proud of building ResQMesh around controlled AI rather than unrestricted AI.

Our workflow demonstrates that prompt engineering can be more than writing a single effective prompt. It can be used to construct an entire decision workflow where each model interaction has a specific purpose.

We built:

A multi stage prompt engineering workflow Structured incident extraction Automated ambiguity detection Human clarification loops Deterministic response planning Adversarial AI review Independent verification gates Dispatcher facing explanations Final human authorization Clear separation between probabilistic AI and deterministic operational logic

Most importantly, the system is designed so that an AI generated response cannot simply bypass verification and become an operational decision.

What we learned

ResQMesh taught us that building an AI system for a high stakes environment requires more than model capability.

We learned how to decompose complex problems into specialized prompt stages, use structured outputs, control context passed to individual LLM calls, detect uncertainty before it propagates, and combine probabilistic models with deterministic algorithms.

We also learned the importance of adversarial evaluation. Instead of asking an AI system only to generate an answer, we can use another controlled AI stage to actively challenge that answer.

Most importantly, we learned that human in the loop design should not be treated as a final checkbox. It should be part of the architecture from the beginning.

What's next for ResQMesh

Our next goal is to move ResQMesh closer to real world emergency response environments through broader testing and stronger integrations.

Future development could include integration with live traffic and road condition data, real time ambulance availability, hospital capacity feeds, richer geospatial information, multilingual emergency reporting, and more extensive evaluation using diverse emergency scenarios.

We also want to strengthen the evaluation framework around the prompt workflow by measuring ambiguity detection, extraction quality, adversarial rejection, verification failures, and consistency across different incident types.

The long term vision is not to replace emergency responders, but to provide them with a reliable decision support layer when every second matters.

ResQMesh turns unstructured emergency information into a verified, explainable response while keeping critical decisions under deterministic and human control.