Fire Finder Agent

The description states that Fire Finder Agent is an agentic wildfire intelligence platform. It gathers current incidents nationwide and correlates data from NIFC/WFIGS, NASA FIRMS, NWS weather, sourced news, field reports, and possible aircraft activity.

It includes a national map ranking incidents by operational urgency to help reviewers focus on fresh changes and unresolved evidence.

Each incident keeps observations, claims, timestamps, confidence, and provenance separate. Aircraft tracks remain quarantined until reviewed and explicitly approved or rejected.

Reviewed evidence moves into Story Studio, which can produce briefing packets with maps, sources, narrative, and video-ready scenes.

The core functionality was reportedly pre-existing; during the hackathon, they built an "Evidence Gate" extension that evaluates six checks before allowing public generation of content.

The author states that wildfire intelligence is fragmented across official incident feeds, satellite detections, weather services, news reports, and field observations. Reviewers must correlate these sources quickly without turning uncertain signals into public claims.

Fire Finder Agent brings this work into one source-grounded, human-reviewed workflow.

During the OpenAI Build Week, they added an "Evidence Gate" to ensure that all outputs (briefings, maps, narratives, videos) go through a safety checkpoint before being released publicly.

This evolution shows a shift from a general platform to a more structured, controlled system for handling sensitive emergency information.

The description does not name specific customers or buyer personas. However, it implies the platform is intended for reviewers or analysts who process wildfire intelligence and need to produce official reports or briefings.

It also suggests that the target users are those responsible for verifying incident data before public release — such as emergency responders, government agencies, or media organizations covering wildfires.

The system is described as analytical context, not an official emergency-alert service.

No evidence of pricing, monetization strategy, or business model is provided in the description. The author does not mention any revenue streams, subscriptions, licensing, or customer acquisition methods.

The platform is built using:

• Rails 8.1
• FastAPI
• PostgreSQL/PostGIS
• MapLibre
• Solid Queue
• Source adapters for NIFC/WFIGS, NASA FIRMS, NWS, news discovery, OpenStreetMap, and OpenSky
• Playwright for end-to-end demo

During the hackathon, they used Codex Desktop with GPT-5.6 to build the Evidence Gate extension.

The gate itself is deterministic and does not require an OpenAI API key, enabling judges to reproduce the decision path without paid credentials.

There is no evidence of traction, customers, or adoption beyond the author's own description. The project was submitted as part of a hackathon event (OpenAI Build Week), and there are no mentions of users, revenue, ARR, or product usage metrics.

The system appears to be in early development stages, with only basic functionality described.

The description does not provide information on competitors or market positioning. No mention is made of existing platforms that do similar work in wildfire intelligence or emergency data correlation.

• Lack of traction: No evidence of real-world usage, customers, or revenue.
• Unverified claims: All statements are self-reported and unverified; no third-party validation.
• Limited scope: The platform is described as analytical context, not an official emergency-alert service — this may limit its utility or market appeal.
• No pricing model: No indication of how the product would be monetized.
• Single founder team: Only one member listed (Chris Vukin), which may signal limited execution capacity.

1. What specific use cases have you identified for this platform?
2. Have you spoken with any potential users or stakeholders in the wildfire response community?
3. How do you plan to validate the accuracy and reliability of the data sources used?
4. Is there a clear path from prototype to production-ready product?
5. What are your plans for scaling beyond the current hackathon-level implementation?