103 points by mapldx 11 hours ago | 28 comments on HN
| Moderate positive Product · v3.7· 2026-03-15 22:05:36 0
Summary Public Safety & Informed Emergency Response Advocates
Signet is an autonomous wildfire detection and alert system providing free, real-time public access to satellite-based fire tracking across the continental US. The platform advocates for informed public participation in emergency response by transparently publishing methodology, data sources, and AI reasoning while explicitly deferring critical safety decisions to official emergency management institutions. The system demonstrates commitment to Article 19 (freedom of information), Article 25 (adequate standard of living and health), and Article 22 (social security) through universal access to life-safety information and integration with official emergency response frameworks.
Rights Tensions1 pair
Art 17 ↔ Art 3 —Use of property-adjacent geospatial data (OpenStreetMap, Census) for fire exposure analysis serves public life-safety (Article 3) but occurs without explicit property-owner consent or notification, creating tension between property privacy and emergency preparedness.
Really interesting approach. The multi-source fusion is where the real value is — any single satellite feed has too many false positives from industrial heat, sun glint, etc. Correlating FIRMS + weather + fuel models is what experienced fire analysts do mentally, so automating that loop makes sense.
On your question about deterministic vs LLM-driven: I'd lean toward keeping the spatial indexing, deduplication, and basic threshold logic deterministic. Those are well-defined problems with known-good algorithms. The LLM adds value where you're synthesizing ambiguous evidence — "is this cluster of weak FIRMS detections near a known industrial site, or is it a new start in timber?" That kind of contextual reasoning is hard to codify as rules.
One operational question: have you thought about how this integrates with existing incident management workflows? Wildland fire teams run everything through ICS structures and often have limited connectivity on the fireline. Being able to push a structured alert (lat/lon, confidence level, fuel type, weather conditions) into their existing tools would be a big deal for adoption.
Interesting. I think there are other services doing the same thing including one linked by another commenter.
When checking the Evidence tab for data that supports the conclusion that there could be a fire in progress I found that it could be improved by excluding the evidence posts for all the mapped fire locations except the one that the user clicked. Presently, if you click that Evidence tab you get a roll of links to posts or mentions or whatever for every fire. I believe that a user would most appreciate data that pertains to the fire they are trying to monitor.
I am not a fan of grey text. It does not improve site navigability or usability and it can get lost in screen glare unless bold grey text is used. It would still be grey text though and I am still not a fan. Perhaps shades of blue or yellow to contrast with the black bar.
Example in case you are thinking of modifying the page - Your top frame has the ap name "SIGNET" in white capitals. Right next to that is an orange dot, probably to signify that something is happening or that the site is "LIVE". Notice that "LIVE" is not only in grey text, beside an orange dot which will be the eyeball magnet, but it is also a smaller font than the ap name "SIGNET".
From my perspective, the site would be improved by changing grey text to a more contrasting color and asking the question - "What information should be the most important topic on this page?" In that way you can optimize it for your users.
Before posting this comment I went back to check that the points I hoped to make were valid points. It turns out that not all "Evidence" links have evidence for every fire on the map. I randomly chose the Custer County Incident when I checked that and found all sorts of stuff pertaining to Texas fires. Perhaps this is not a huge problem for you to solve. I checked the Rapides Parish Incident in Lousyana and it only has data about that event.
Aggregating disparate government feeds with completely out-of-phase polling schedules into a unified state machine is notoriously painful. I am curious how your Go service handles the rate limits of the NWS API, which historically drops connections right when usage spikes during actual emergencies. If you ever expose this via webhooks, it would make an incredible backend for building localized mobile push notifications where standard cell-broadcast alerts are too broad or slow.
We do some similar work with hotspot analysis but (as a Canadian company) are more focused on Canadian data where the government already does a fair bit of false positive detection and filtering. It generally gives pretty clean data and we can scrub historical data over time like this: https://imgur.com/a/gCJGzqd
The dataset includes US coverage but it's not filtered the same way and FAR more noisy, so I appreciate efforts like this. We haven't got there yet but if you were looking for something deterministic and automatable the Canadian gov's process is potentially worth learning about.
They also produce perimeter estimates based on the hotspots which we can extract and put into a physics-based fire growth model like Prometheus or FARSITE to estimate future fire behaviour based on forecasted weather. This gives very actionable and deterministic estimates of future fire behaviour. We also have worked on a risk model that determines the likelihood of that future fire growth interacting with various assets on the landscape (urban interface areas, power lines, fuel pipelines, forest inventory, etc) and calls out high risk areas. One thing we've been wondering if where LLMs fit into any of this (if at all) so appreciate seeing what others are doing.
the Go choice makes a lot of sense for this. i've been wiring up government data sources for a different project and honestly the format inconsistency between agencies is always the real headache, not the actual processing
curious about the 23 tools though -- are those all invoked through one Gemini orchestration pass or is there a routing layer picking which subset to call per detection? feels like that'd stack up fast latency-wise
I did the similar thing on https://www.crimewatches.com/, the only pain point is how to aggregate sex offenders' profiles properly across US, too much legal risk there plus labor intensive manual work, you cannot pull the data out easily, CF CAPTCHA gated and short lived token, but will have huge impact on local communities.
Right, that's a clean way to frame the boundary. Appreciate it.
On ICS integration, I haven't gotten there yet. The system outputs structured incident records, but I don't have real operational experience on that side.
The limited-connectivity point is interesting. If the output is a compact structured record that doesn't need a live connection to be useful, that could change what integration looks like.
If you have a strong opinion on what people actually use there, I'd be interested.
Fair points, I leaned a little hard into the ops aesthetic. Grey text might not be doing anyone any favors.
On the Evidence tab, I agree that it should be incident-specific to be useful on its own. Right now the model scopes what evidence gets attached, so probably a case where that should be deterministic instead.
Honestly, not robustly enough yet. I've already been hitting timeouts on NWS gridpoint forecasts.
Right now some weather failures don't stop the rest of the assessment loop. Successful fetches get persisted so the system builds historical weather context over time.
The webhook idea is interesting. The monitoring loop is already separated from the web layer, so publishing to external consumers would be a natural extension.
Good call. The system does try to match to official reporting and update when it finds one, but the working names in the meantime could definitely cause confusion.
Probably another case where that should be deterministic instead of model-generated. Thanks.
Thanks, this is really helpful. That filtering/perimeter pipeline is exactly the kind of deterministic path I'm interested in learning from, especially for pushing more of the false-positive reduction upstream before the model gets involved at all.
My take so far is that models seem most useful in the contextual triage step and in synthesizing multiple sources into a structured assessment. But most of the system around that is and should be deterministic.
The physics-based approach you're describing makes a lot of sense to me for spread prediction - different tool for a different part of the problem.
If there's a public writeup on the filtering process you'd recommend, I'd love to take a look.
Not all 23 get invoked in one pass. The system runs 4 different types of cycles, each with its own Gemini call, and within a cycle the model picks a subset of tools based on the context rather than fanning out to everything.
Over the last week, the median ends up being about 6 tool calls across 4 distinct tools per cycle.
Latency-wise, median completed cycle time is about 37s overall. The heavy path is FIRMS: about 135s median / 265s p90 over the same window.
It runs asynchronously in the background, so the web UI isn’t blocked on a cycle finishing, though cycle latency still affects how quickly new detections get enriched.
High A:public-health A:adequate-standard-living A:medical-attention F:life-protection
Editorial
+0.60
SETL
+0.17
Core mission addresses right to adequate standard of living and medical attention by enabling emergency response and evacuation. Fire safety is prerequisite for maintaining adequate living conditions and physical health.
FW Ratio: 60%
Observable Facts
System integrates satellite detection, weather data, and geographic exposure analysis specifically to support 'fire behavior, nearby exposure, and likely persistence' assessment.
Alert signup enables individuals to receive warnings before fire affects their residences or access to medical care.
Disclaimer directs users to 'refer to NIFC, InciWeb, and your local emergency management agency' for official guidance, supporting integration with medical and emergency response systems.
Inferences
Fire detection and alert infrastructure directly supports individuals' ability to maintain adequate living standards and access medical care by enabling evacuation and emergency response.
Integration with official emergency management systems positions Signet as enabling institution for right to adequate standard of living.
High A:information-freedom A:transparency F:open-data
Editorial
+0.55
SETL
+0.17
System explicitly designed to make wildfire information publicly available. Methodology descriptions, data sources, incident logs, and AI decisions are transparent. Disclaimer about AI limitations supports informed consumption of information.
FW Ratio: 60%
Observable Facts
Page includes 'How Signet Works' modal explaining autonomous orchestration, multimodal reasoning, and technical architecture with specific data sources.
Feed displays 'incident updates, and prediction outcomes' transparently rather than hiding behind single final answers.
Disclaimer explicitly acknowledges limitations: 'AI-generated assessments may contain errors. Satellite data may be delayed or incomplete.'
Inferences
Commitment to displaying 'raw FIRMS detections, interpreted GOES observations, weather inputs, predictions' in structured tables indicates belief that informed public requires visibility into data and reasoning, not polished conclusions.
Voluntary disclosure of system limitations and reliance on NIFC cross-checking supports Article 19's requirement to impart information without frontiers and without regard to borders.
Core mission centers on protecting life by providing early warning of fire activity. System explicitly designed to enhance survival chances through continuous autonomous monitoring and alert generation.
FW Ratio: 60%
Observable Facts
System description states 'Autonomous monitoring · Always follow official emergency guidance,' positioning the tool as life-protection infrastructure.
Alert system allows users to register for notifications of fire activity, providing early warning capability.
Disclaimer explicitly advises 'Do not use this system to make evacuation, safety, or emergency response decisions,' acknowledging that life-or-death decisions require official guidance.
Inferences
Integration of satellite detection, weather data, and AI reasoning suggests multi-layered approach to ensuring no life-threatening fire activity goes undetected.
Alert registration system demonstrates structural commitment to reaching individuals before fire threatens them.
Medium A:dignity-public-safety A:informed-consent F:transparency-over-certainty
Editorial
+0.35
SETL
-0.14
Preamble emphasizes human dignity and informed decision-making through public access to wildfire information. Content frames autonomous systems as tools to enhance human agency ('people have the right to know about fire activity affecting their communities'), not replace official authority.
FW Ratio: 60%
Observable Facts
Page header states 'Autonomous Wildfire Tracking' with explicit directive 'Always follow official emergency guidance.'
Disclaimer modal declares 'Signet is not a substitute for official emergency information.'
Alert signup form allows users to enter ZIP codes to receive notifications of fire activity nearby.
Inferences
The emphasis on 'Always follow official emergency guidance' indicates recognition that human dignity and safety depend on informed deference to competent authorities, not on autonomous systems alone.
Free public access to tracking data without authentication gates suggests commitment to universal availability of safety information.
Medium A:social-order A:rights-framework F:official-integration
Editorial
+0.35
SETL
-0.14
Content explicitly positions Signet as supporting social order built on official emergency management. Repeated emphasis on following NIFC, InciWeb, and local guidance indicates commitment to rights-enabling institutions.
FW Ratio: 67%
Observable Facts
Disclaimer states: 'Signet is not a substitute for official emergency information. Do not use this system to make evacuation, safety, or emergency response decisions.'
System references official feeds and recommends users 'refer to NIFC, InciWeb, and your local emergency management agency.'
Inferences
Repeated deference to official institutions indicates understanding that rights-enabling social order depends on competent, trustworthy public institutions, not autonomous systems alone.
Content treats all individuals as equal participants in fire-affected communities. No differentiation of access based on identity or status. Data-driven approach assumes equal entitlement to situational awareness.
FW Ratio: 67%
Observable Facts
Wildfire alert system monitors activity 'near your area' using ZIP code, treating all geographic locations equally.
Page includes no login requirement, payment gate, or identity-based access restrictions for core map and feed.
Inferences
ZIP-code-based alert mechanism suggests an underlying principle that fire safety awareness applies equally to all residents regardless of socioeconomic status or institutional affiliation.
Medium A:social-welfare A:public-safety F:collective-benefit
Editorial
+0.30
SETL
+0.12
System explicitly designed for collective social benefit (fire safety across continental US). Free public access ensures realization of right to social security and services.
FW Ratio: 67%
Observable Facts
System provides autonomous wildfire tracking as public good with no subscription, account requirement, or payment structure.
Alert system enables individuals to participate in public safety infrastructure by registering for notifications.
Inferences
Design as free public utility reflects understanding that fire safety is collective social right, not commodity.
System minimizes personal data collection. Only ZIP code requested for alert signup; no demographic profiling, behavioral tracking, or unnecessary identity collection observable.
FW Ratio: 50%
Observable Facts
Alert signup form requests only 'ZIP CODE' input with no email, name, phone, or account creation required.
Cloudflare Turnstile CAPTCHA present but no Google Analytics, Facebook Pixel, or other commercial tracking libraries observed in provided HTML.
Inferences
Minimal data collection (ZIP code only) suggests design principle of privacy minimization for public safety feature.
Absence of observable third-party tracking infrastructure supports inference that user behavior is not being profiled.
Medium A:cultural-participation A:scientific-benefit F:open-data
Editorial
+0.25
SETL
-0.12
System demonstrates commitment to scientific benefit by publishing methodology, data sources, and reasoning transparently. Data-driven approach enables research community to build on work.
FW Ratio: 67%
Observable Facts
Page describes 'Technical Architecture' with emphasis on structured data persistence for visibility and reproducibility.
Transparent methodology and structured data architecture suggest commitment to enabling researchers and institutions to benefit from and build upon work.
No explicit content addressing duties or community responsibilities, though system design implies individual duty to follow official guidance.
FW Ratio: 67%
Observable Facts
Disclaimer explicitly warns: 'Do not use this system to make evacuation, safety, or emergency response decisions.'
Page directs decisions to official agencies rather than empowering autonomous action.
Inferences
Refusal to make critical safety decisions reflects recognition that individual duties to community and state require deferring to competent authorities, not autonomous algorithms.
No observable editorial content addressing property rights.
FW Ratio: 67%
Observable Facts
System description lists 'NWS, USGS, LANDFIRE, Census, OpenStreetMap' as data sources for 'nearby exposure' analysis.
No observable property-owner consent process or property-data protection mechanisms.
Inferences
Use of property-adjacent data (Census, OpenStreetMap) without explicit property-owner consent or notification may create minor tension with property owners' right to privacy regarding property location and characteristics, though wildfire risk is a legitimate public safety concern.
No privacy policy, cookie notice, or data handling statement observable on accessible page content.
Terms of Service
—
No terms of service observed in provided content.
Identity & Mission
Mission
+0.15
Article 3 Article 25
Mission statement emphasizes autonomous wildfire tracking and safety awareness ('Always follow official emergency guidance'). Explicitly disclaims substitute for official information, supporting public safety and informed decision-making.
Editorial Code
+0.12
Article 19 Article 20
Clear disclaimer about AI limitations and data reliability. Transparency about data sources (NASA FIRMS, GOES-19, NWS, USGS, LANDFIRE) and methodology promotes informed public discourse.
Ownership
—
Developed by 'zachary.systems' (linked). Clear attribution but limited public information about organizational structure or governance.
Access & Distribution
Access Model
+0.10
Article 25 Article 27
Free, real-time public access to wildfire tracking data with no apparent paywall. Alert signup available. Supports universal access to critical safety information.
Ad/Tracking
—
No advertising or tracking infrastructure observable in provided HTML/CSS. Cloudflare Turnstile CAPTCHA present but no third-party ad networks detected.
Accessibility
-0.08
Article 2 Article 20 Article 25
Page includes sr-only elements and responsive design for mobile, but CSS-only visual design with minimal semantic HTML structure may limit screen reader usability. Dark theme with low-contrast text (#888 on #0a0a0a) creates accessibility barriers.
High A:public-health A:adequate-standard-living A:medical-attention F:life-protection
Structural
+0.55
Context Modifier
+0.17
SETL
+0.17
System provides essential infrastructure for emergency management agencies, individuals, and medical responders to locate and respond to fire threats. Real-time data enables medical evacuation decisions and health-critical response.
High A:information-freedom A:transparency F:open-data
Structural
+0.50
Context Modifier
+0.12
SETL
+0.17
Real-time map and feed provide unrestricted access to structured fire incident data. Technical architecture description ('Assessments, tool calls, incident updates, and prediction outcomes stay visible in the live feed') commits to radical transparency over hidden algorithms.
Medium A:dignity-public-safety A:informed-consent F:transparency-over-certainty
Structural
+0.40
Context Modifier
0.00
SETL
-0.14
Site provides free, public real-time access to critical safety data without friction. Alert system and transparent methodology support individuals making autonomous decisions about safety. Turnstile CAPTCHA protects against abuse while preserving access.
Medium A:social-order A:rights-framework F:official-integration
Structural
+0.40
Context Modifier
0.00
SETL
-0.14
System integrates with official incident feeds ('Official cross-checking currently relies on the NIFC IMSR current incident feed'). Architecture designed to complement rather than replace official emergency management structures.
System provides uniform access to wildfire tracking data across continental US without geographic, economic, or demographic stratification of core features. ZIP-code-based alert system treats all geographic locations equally.
Real-time satellite monitoring, automated alert dispatch, and structured incident logging directly support preservation of life. Free access ensures no economic barrier to life-saving information.
Alert system captures ZIP code only (not full address or personal identifiers). No observable third-party tracking scripts, analytics, or advertising networks that would enable inference of private behavior.
Medium A:cultural-participation A:scientific-benefit F:open-data
Structural
+0.30
Context Modifier
+0.10
SETL
-0.12
Structured data persistence ('Persists raw FIRMS detections, interpreted GOES observations, weather inputs, predictions, and official cross-checks in structured tables') suggests architecture designed for scientific reproducibility and research access.
Public map and real-time alert system enable communities to coordinate around shared fire safety information. No observable restrictions on collective use or community-based response planning.
Medium A:social-welfare A:public-safety F:collective-benefit
Structural
+0.25
Context Modifier
0.00
SETL
+0.12
Free universal access to critical fire safety information serves as public good. No paywalls, identity barriers, or exclusion mechanisms prevent individuals from realizing right to benefits of collective fire management infrastructure.
Free public access to map and fire tracking data enables individuals to make autonomous decisions about where to go or avoid. No geofencing, movement restrictions, or location-based access controls.
System stops short of making evacuation or response decisions, relegating those to official authorities. Architecture respects boundaries of autonomous system responsibility.
Dark theme with low-contrast text (#888 on #0a0a0a background) and CSS-dependent visual hierarchy create barriers for users with color vision deficiency or low vision. Responsive mobile design mitigates some exclusion but layout complexity may disadvantage users relying on screen readers or keyboard navigation.
System uses satellite data, weather data, and geographic information (OpenStreetMap, Census, USGS, LANDFIRE) without explicit property-owner consent mechanisms. Analysis references 'nearby exposure' suggesting property-adjacent analysis, but no property-owner notification or data protection structures observed.
System designed to protect rather than undermine UDHR rights. No observable attempts to suppress information, restrict access, or enable authoritarian use.
Supplementary Signals
How this content communicates, beyond directional lean. Learn more