# Project export: Flashpoint: AI Wildfire Incident Commander This document was generated by HackStack to give an AI agent context about a hackathon project. Sections are labeled with their provenance; content marked as truncated was cut to keep this document small. ## Project metadata - Hackathon: TreeHacks 2026 - Tagline: AI Command Center for Wildfire Response - Devpost: https://devpost.com/software/flashpoint-ai-wildfire-incident-commander - GitHub: not linked - Demo: http://flashpoint-commander.vercel.app/ - Team: contributor stats unavailable ## Devpost submission (written by the team) ### Inspiration Wildfire initial attack is a clock. In the first 0–3 hours, incident commanders are forced to make high-stakes calls with incomplete information: Where will the fire go next? Which community is at risk first? Do we need evacuation warnings? What resources do we request now? We built Flashpoint around a simple product promise: “3 decisions in 10 seconds.” A decision-support prototype that turns messy live signals into clear, explainable next steps for the initial attack window. ### What it does Flashpoint is a specialized Incident Commander decision support system for the 0–3 hour initial attack phase. It combines: Live incident detection from NASA FIRMS (satellite hotspots) → clustered into fire “incidents” Operational context from weather + NWS alerts (+ optional CAL FIRE / perimeters) Physics-inspired spread envelopes (1h / 2h / 3h) with wind direction + optional wind shift Three ranked Action Cards (Evacuation / Resources / Tactics) with “Why” bullets + confidence A specialized chatbot (centerpiece) that is: Incident-aware (always operates on the selected incident) Tool-grounded (must cite tool outputs like [tool:get_weather]) Doctrine-backed (RAG retrieval from IRPG/FOG/ICO/10&18 Watchouts like [KB:irpg#12]) Structured for IC workflows: decision, evidence, actions_0_3h, uncertainties Resilient: deterministic fallback still works if AI is unavailable Incident-aware (always operates on the selected incident) Tool-grounded (must cite tool outputs like [tool:get_weather]) Doctrine-backed (RAG retrieval from IRPG/FOG/ICO/10&18 Watchouts like [KB:irpg#12]) Structured for IC workflows: decision, evidence, actions_0_3h, uncertainties Resilient: deterministic fallback still works if AI is unavailable ### How we built it Live fire detection (Live Mode) NASA FIRMS hotspots (VIIRS) → parsed from CSV → clustered with DBSCAN-style clustering into “fire events” For top incidents we enrich with: Open-Meteo weather (wind/humidity/temp) NWS alerts (e.g., Red Flag Warnings) Optional: CAL FIRE incident pages + ArcGIS perimeters Open-Meteo weather (wind/humidity/temp) NWS alerts (e.g., Red Flag Warnings) Optional: CAL FIRE incident pages + ArcGIS perimeters API: /api/fires/live Spread modeling (0–3h) We implemented an explainable spread model (not a black box). The spread rate is: [ \text{rate} = \text{baseRate} \times \text{windFactor} \times \text{humidityFactor} \times \text{fuelFactor} ] Then we generate cone/ellipse polygons oriented by wind direction for 1h / 2h / 3h envelopes, with support for wind shift scenarios. API: /api/spread Action Cards (recommendations) We generate three action categories: Evacuation Resources Tactics Cards are ranked using a multi-factor score (risk + time-to-impact + proximity to assets/communities + operational constraints) and always include explainable “Why” bullets. API: /api/recommendations Specialized chatbot (tool-use + doctrine grounding) The chatbot is not a generic wrapper. It uses: Preflight automation: if context is missing, it auto-runs get_weather → compute_spread → get_action_cards Tool grounding: facts must cite tool outputs like [tool:compute_spread] RAG doctrine: retrieves relevant sections from IRPG/FOG/ICO/Watchouts and cites them [KB:...] Safety guardrails: decision support language (recommendations + triggers), not dispatch Deterministic fallback when AI is unavailable API: /api/chat, /api/kb/search Challenges we faced Real-time data is messy: FIRMS hotspots are detections, not perimeters — clustering and prioritization mattered a lot. Latency and reliability: we added caching (FIRMS TTL, NWS TTL) and made the system degrade gracefully. Hallucinations: we implemented server-side validation so ungrounded claims are filtered unless supported by tools / KB snippets. Integration complexity: maps, GPU layers, geospatial math, and tool orchestration had to stay fast and explainable. ### What we learned A good safety-critical assistant is less about “smart words” and more about grounded computation + evidence + workflow fit. Explainability (risk breakdown + citations) makes recommendations more usable than raw predictions. A robust demo needs graceful failure modes — deterministic cards + briefs still deliver value. ### What's next Time-slider spread timeline (15-min steps to 3 hours) with “likely vs worst-case” envelopes Better operational overlays: roads, communities, critical infrastructure Stronger historical learning using curated incident reviews + structured outcomes Field usability: mobile-friendly briefing export + offline mode Safety note Flashpoint is a hackathon decision-support prototype designed for training and situational awareness. Real wildfire response should follow official procedures and command structures. ## README (from the GitHub repository) No README available. ## Detected evidence (automated analysis) No repository was indexed for this project. Claimed technologies below could not be checked against code. - Next.js (technology) — claimed on Devpost, not found in the code - React (technology) — claimed on Devpost, not found in the code - Tailwind CSS (technology) — claimed on Devpost, not found in the code - TypeScript (language) — claimed on Devpost, not found in the code - Vercel (technology) — claimed on Devpost, not found in the code ## Codebase structure No repository index available. ## Key source files No repository index available; no source files included.