Fire Finder Agent

Inspiration

Wildfire intelligence is fragmented across official incident feeds, satellite detections, weather services, news reports, and field observations. Reviewers have to correlate those sources quickly without turning uncertain signals into public claims.

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

What it does

The platform gathers current incidents nationwide and correlates NIFC/WFIGS, NASA FIRMS, NWS weather, sourced news and field reports, and possible aircraft activity. A national map ranks incidents by operational urgency so reviewers can focus on fresh changes and unresolved evidence.

Each incident keeps observations, claims, timestamps, confidence, and provenance separate. Possible aircraft runs remain quarantined until a reviewer compares the track against the official perimeter and explicitly approves or rejects it.

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

What we built during OpenAI Build Week

The core incident workspace existed before Build Week. During the event we built Evidence Gate: a persistent safety checkpoint that runs before any public report, StoryMap, narration, or video can be generated.

Evidence Gate evaluates six visible checks:

• authoritative source coverage
• perimeter, thermal, and weather coverage
• evidence freshness
• quarantine of unverified leads
• claim consistency
• authoritative provenance for public-safety language

Every run stores its score, findings, operator, scope, and evidence snapshot. If a source or review decision changes, the previous audit becomes stale and generation locks again.

The demo uses a current Box Springs incident. The first audit identifies stale evidence and two unreviewed aircraft candidates. A reviewer rejects N350HA, approves JPR62 after inspecting each track against the official perimeter, and reruns the gate. The score rises from 84 to 92, while generation remains correctly blocked on the remaining freshness warning.

How we used Codex and GPT-5.6

We built the Evidence Gate extension in Codex Desktop with GPT-5.6. Codex helped us trace the existing Rails data flow, choose a safe integration boundary, implement the migration, service, model, controller, locks, UI, and tests, and create the reproducible Playwright demo.

GPT-5.6 helped design deterministic checks and adversarial cases for pending leads, stale evidence, disputed claims, and safety-sensitive language. We also used Codex to audit the git history so the submission clearly separates pre-existing platform work from the functionality added during Build Week.

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

How it is built

Fire Finder Agent combines Rails 8.1, FastAPI, PostgreSQL/PostGIS, MapLibre, Solid Queue, and source adapters for NIFC/WFIGS, NASA FIRMS, NWS, news discovery, OpenStreetMap, and OpenSky. Playwright drives the reproducible end-to-end demo.

Challenges and lessons

The hardest problem was preserving uncertainty. Proximity does not prove that an aircraft is fighting a fire, a community report is not an official alert, and old evidence should not silently pass. The system therefore preserves provenance, quarantines uncertain leads, and requires a human decision before generation.

What's next

Next we will expand reviewer routing, automate freshness recovery, strengthen incident-change detection, and generate exportable briefing packets only after every gate requirement is satisfied.

Fire Finder Agent is analytical context, not an official emergency-alert service.

Built With

• codex
• docker
• fastapi
• gpt-5.6
• maplibre
• nasa-firms
• nws
• openai
• opensky
• playwright
• postgis
• postgresql
• python
• railway
• ruby
• ruby-on-rails
• wfigs