Beacon

Concept

Concept Stage Beacon is a concept under exploration in UnGovr Labs. The operating model and scenarios described below represent our current thinking, not a built product.

Overview

Disasters create short windows where crowdsourced eyewitness data is genuinely useful — photos of flooded streets, structural damage after an earthquake, debris on evacuation routes, observed plume direction in a chemical release. The information exists; people are already taking the photos. What's missing is a structured channel for getting that data to the emergency operations center that can act on it.

Beacon is a time- and place-bounded mode where an authorized agency activates a public call for information during a specific event. Unlike always-on reporting tools, Beacon is lit for an event and extinguished when the event ends — with retention policies declared up front.

Operating Model

Activate. An authorized agency role lights a beacon — event type, geographic boundary, time window, what to collect.
Reach. The public sees the active beacon (web, SMS, push) and contributes photos, location, short text, optional structured fields.
Aggregate. Submissions stream into a clustered incident view for the EOC, with multi-witness confirmation surfacing high-signal reports.
Expire. The beacon shuts off automatically; data follows pre-declared retention.

Scenarios

FloodingPhotos of flooded streets and water depth indicators. Helps EOC prioritize rescue and route closures.

EarthquakeBuilding damage, gas leaks, collapsed structures. Helps inspectors triage and identify URM failures.

Wildfire evacuationSmoke columns, road conditions on evacuation routes, sightings of stranded animals or people.

Hazmat releasePlume direction, smell reports, observed wildlife and livestock impacts.

Missing personGeo-bounded sighting reports during an active search window.

Power outage extent"Is your block out?" pings to map outage geography faster than utility ICS reports.

Severe storm damagePost-event damage assessment to support FEMA / CalOES IDA submissions.

Pre-staged setup

For a beacon to launch in minutes during a real event, an agency does some work ahead of time: designate authorized activators, pre-declare common beacon templates with their forms and retention windows, configure default downstream recipients, pre-publish a public-facing landing page so the first time residents see Beacon isn't during a crisis, and connect to existing notification channels.

Open questions

Trust and verification. How do we surface high-confidence reports vs. noise, duplicates, or malicious submissions?
PII and privacy. Faces and license plates in photos. Auto-blur on intake? Per-beacon disclosure rules?
Retention. Default short, with explicit "preserve for after-action / FEMA IDA" carveout. Avoid becoming a permanent surveillance archive.
Authorization. Who can light a beacon? Tiered — local jurisdictions for routine, county or state OES for cross-jurisdictional.
Public dashboard vs. EOC-only. Some events benefit from public situational awareness, others should stay internal until vetted.
Interop. Push beacon-derived data into agency systems they already use — WebEOC, ArcGIS, NIEM-EM, OASIS CAP.

Relationship to other UnGovr Request projects

Beacon shares geocoding, jurisdiction routing, SMS intake, and Open311-style downstream delivery with Service Routing. It differs from Spotter in operating mode — Beacon is bursty and agency-activated, Spotter is always-on and public-initiated. It differs from Rumble in input source — Beacon is human-submitted, Rumble is machine telemetry.

Status

Concept stage. Tracked at issue #932.