White paper · Public alerting
Prove, Authorize, Send, Correct
An Accountable Model for Public Alerts
Public warning is not one send action. This paper separates incident evidence, alerting authority, message validation, human release, channel handoff, and correction into an accountable model for bounded evaluation.
Narrated film · 1:10
A public warning changes. Every channel needs the correction.
Follow one correction across languages and jurisdictions, and see the difference between sending an update and knowing it arrived.
An authored scenario that explains the idea. Read the story and its limits.
▶ 1:10
Jump to a section in this paper
The alert is a chain, not a button
A public alert compresses extraordinary responsibility into a short message. A source supports a warning decision. A designated incident, health, law-enforcement, or other substantive authority determines the protective action under the applicable law and plan. An authorized alerting organization selects the audience, area, time, event code, and channels and encodes that instruction. A person with message-release authority approves the exact alert. Systems accept, reject, transform, or deliver it. Conditions may then require an update, correction, or cancellation.
Treating that chain as one successful “send” hides its most important distinctions. A verified sensor reading is not permission to warn. A valid message is not an authorized message. Acceptance by a gateway is not presentation on every device. Presentation is not receipt by every intended person, and receipt is not understanding or protective action. A correction does not erase the record that made it necessary.
The objective is accountable continuity: preserve what was known, who could act, which text was approved, what each channel reported, and how later information changed the instruction. This paper describes the official record, then presents a separate Grid proposition for evaluating that continuity. The cited institutions do not describe or endorse Grid.
What official sources establish
FEMA's December 2024 IPAWS sign-up fact sheet identifies eligible government and public-safety organizations, with some others potentially eligible because of their mission. Application includes training, an agreement with FEMA, compatible alert-origination software, and public-alerting permissions. Those permissions define geographic jurisdiction, event codes, and primary pathways and receive review by the designated state official or Tribal leadership, as applicable.
Those pathways include the Emergency Alert System, Wireless Emergency Alerts, NOAA Weather Radio through non-weather emergency messages, and the IPAWS All-Hazards Information Feed. Authority is consequently scoped: an authenticated user, a technically valid message, or access to an interface does not establish permission to use every event code, geography, or channel.
FEMA's current IS-247.C course for IPAWS alert originators teaches a staged process: determine need; review procedures, permissions, and hierarchy; select pathway, area, event code, and data elements; then compose and assess. FEMA's IPAWS Best Practices Guide recommends permitted-code templates, exercise practice, care with copied text, and testing linked-site capacity and trustworthiness. These are disciplines, not a finding that a draft is correct.
The OASIS Common Alerting Protocol Version 1.2 is an open format for exchanging all-hazard alerts across networks. A CAP alert has a sender identifier, message identifier, sent time, status, message type, and scope. Information blocks can express language, event, urgency, severity, certainty, audience, timing, instructions, geography, and resources. CAP also defines Alert, Update, Cancel, Ack, and Error types and references linking later messages to earlier ones.
CAP deliberately does not specify a particular application or telecommunications method. Schema conformance can show that a document meets represented format rules; it does not show that the incident facts are sound, that the sender has IPAWS authority, that an alert satisfies every profile or channel rule, or that the public received or understood it.
For WEA, the FCC's June 2025 small-entity compliance guide describes authorized officials sending through FEMA IPAWS to participating providers, which transmit to compatible devices in the target area. Device functions include subscriber choices, language preferences, presentation, and duplicate suppression. A sender-side receipt is not evidence that every intended handset displayed the message.
Six records that must remain distinct
An accountable alert lifecycle needs connected records without collapsing their meanings.
1. Event and source
Record each material claim, source organization or device, observation time, acquisition path, revision, supplied qualification, and handling limit. Distinguish event time from draft time. A source can be authentic yet stale; reputable sources can conflict; a map can be newer than its underlying observation.
When required evidence is missing, expired, or contradictory, the model should show unresolved, not silently select the most convenient fact. CAP's required sender identifies the alert originator and its optional source can name an operator or device, but those fields do not by themselves carry the complete evidentiary chain behind an incident claim.
2. Alerting-authority scope
Bind the proposed alert to the actual organization, trained role, delegation, jurisdiction, permitted event codes, pathways, and effective period. Bind separately to the source record or authorization for the underlying protective action. Authentication answers who accessed the system. IPAWS permission answers whether that actor may release this kind of warning here, now, through these channels; it does not itself confer authority to order an evacuation, health action, or other substantive instruction. An out-of-scope proposal should stop or escalate before channel submission.
3. Message construction and validation
Preserve audience, location, hazard, timing, action, attribution, trusted information link, language variants, accessibility review, and channel renderings. Validate fields, values, geography, length, characters, references, and expiration. Keep technical validation separate from content review: well-formed text can still name the wrong zone, action, time, or translation.
4. Human authorization
Show the exact message revision presented, the evidence and conflicts the authorized person saw, their decision, identity, authority basis, time, and conditions. If the text, area, event code, pathway, or source basis changes, approval should not carry forward automatically. The policy owner defines when reauthorization is required; a workflow label cannot.
5. Channel handoff and evidence
Record every attempted pathway: authorized revision, adapter and profile version, submission time, response, error, retry, and returned identifier. Distinguish queued, submitted, accepted by an intermediary, rejected, timed out, and channel-specific downstream evidence. CAP Ack and Error have message-level meanings, but acknowledgment is not proof of every later hop, individual presentation, comprehension, or action.
Partial handoff is therefore a first-class state. EAS may accept while a WEA submission fails; one language variant may pass while another is rejected; an internet page may be unavailable even though an alert containing its URL was distributed. The operating view should expose that divergence instead of summarizing it as “sent.”
6. Update, correction, cancellation, and outcome
Preserve the initial alert and every revision. An update should name the change and reference the earlier message. A correction should identify the wrong or stale fact and carry authorized text. A cancellation should reference what it cancels without implying every recipient saw it or treating the cancellation itself as an all-clear message. Superseded content remains in the audit record.
Public understanding is a separate question. Call-center questions, community feedback, surveys, web demand, rumor monitoring, and after-action review may supply evidence under privacy and records rules. None proves perfect channel performance or that the warning caused an outcome.
The Grid proposition
Grid proposes representing these records as a governed, reactive decision model. Named inputs carry source and time. Explicit predicates evaluate freshness, conflicts, authority scope, required fields, language and accessibility review, and channel-specific preconditions. A proposed message binds to those inputs and to a model revision. A human authorization binds to the exact proposal. Simulated or configured adapters return per-channel evidence. Updates and cancellations form a versioned reference chain rather than overwriting history.
In shorthand:
Prove the event basis → record protective-action authority → prove alerting permission → construct and validate → obtain exact-message authorization → hand off by channel → observe, update, correct, or cancel
This is an architecture proposition for evaluation. Grid does not originate real alerts, confer public-warning authority, certify CAP, IPAWS, or WEA compliance, prove delivery or public understanding, replace 911 or dispatch, guarantee system or channel availability, or establish protective-action or public-safety outcomes. It does not make stale data current, resolve disputed facts, create a qualified translation, decide accessibility sufficiency, or make an authorized person's judgment sound. Any live integration, security authorization, records schedule, operating procedure, and approval remains the responsible organization's work.
Language, accessibility, records, and security
CAP permits multiple information blocks and language identifiers. It does not translate a warning or establish equivalent meaning. Communities need qualified language review, consistent place names and actions, and approved variants tied to the same event revision. Channel language features have implementation conditions and dates; teams should validate current support.
FEMA's accessibility guidance for alert originators recommends usable language, minimal abbreviations, important information first, care with text-to-speech, consistent audio and text, and explanation of images and maps. Technical checks can find omissions or mismatches. Relevant experts must judge whether the message works for the community and channels.
The record should include source references, message and model revisions, validations, authorization, submissions, responses, changes, and operator actions. CAP identifiers and references help reconstruct a chain; they do not define retention, disclosure, evidentiary, privacy, or public-records obligations. Records owners and counsel establish those rules.
Security surrounds the chain: strong identity, least privilege, protected credentials and signing material, approved interfaces, tamper-evident logs, recovery, and revocation. The NIST Cybersecurity Framework 2.0 offers non-prescriptive outcomes organized around Govern, Identify, Protect, Detect, Respond, and Recover. It can structure risk questions; it does not authorize a system or prescribe one implementation. Independent fallback procedures remain necessary because the model cannot guarantee any service's availability.
Fictional exercise: the Harbor County water notice
The following scenario is entirely fictional. Harbor County, its agencies, sources, zones, times, and public-health instructions are invented for an exercise; this is not real health advice and no message enters a live alerting system.
At 08:10, a simulated treatment-plant feed reports pressure loss in invented Zone East. At 08:14, a laboratory feed still shows an earlier normal sample. The model labels the facts different in kind and time: the sample does not verify conditions after the pressure loss. Under the fictional exercise plan, a designated public-health role supplies an exercise-only protective-action determination and the required source references.
The originator selects a permitted exercise code, Zone East polygon, English and Spanish variants, and fictional preapproved instructions. Validation finds that the Spanish variant names Zone West. The proposal stops. A qualified exercise translator corrects it, both variants are reviewed, and the fictional warning authority authorizes revision 3.
No real alert is sent. Two simulated adapters receive authorized message HC-003. The EAS adapter returns an exercise acknowledgment while the WEA adapter returns a simulated timeout before acceptance. The model reports partial handoff and retains both responses. An unchanged retry of HC-003 later receives a simulated WEA acceptance; neither response is labeled public delivery.
At 09:05, a new simulated source narrows the area. A technical operator's attempt to submit the changed polygon under the old authorization is blocked. The fictional warning authority approves HC-004 as an exercise Update, with the full related-message reference set required by the exercise profile. Later, exercise Cancel message HC-005 references the active related messages after the invented condition ends. In the fixture, the cancellation stops further rebroadcast; it is not an all-clear message.
The exercise does not show public receipt, understanding, or action. It tests provenance, a language defect, a blocked unauthorized change, partial handoff, reauthorization, and correction reconstruction.
A bounded evaluation that can produce evidence
Start with one alert class, jurisdiction, written authority chain, small channel set, and synthetic or historical cases that cannot trigger public effects. Baseline time from source report to authorized draft, manual handoffs and rekeys, validations, retained channel evidence, correction time, and reconstruction of one past alert. Do not assume improvement.
Predefine fixtures and expected dispositions with alerting, communications, language-access, security, records, and technical owners. Seed a stale observation; conflicting sources; an authenticated but unauthorized originator; an out-of-scope polygon or event code; an omitted or meaning-changing language variant; a malformed CAP value; a wrong update reference; an expired draft; one rejected channel; a delayed acknowledgment; a duplicate; and an unauthorized correction.
Measure at least six groups:
- Provenance: required claims linked to source, observation time, and revision; stale and conflicting facts surfaced; zero seeded unsupported facts silently promoted to verified.
- Authority: proposals evaluated against role, jurisdiction, event, channel, and time scope; zero seeded out-of-scope releases allowed inside the test boundary; authorization tied to the exact approved revision.
- Message integrity: expected CAP and channel validations; seeded geography, language, reference, expiration, and character defects detected; reasons visible for blocking or authorizing.
- Handoff evidence: per-channel submissions and responses retained; accepted, rejected, timed-out, and partial states reported separately; no intermediary receipt mislabeled as public delivery.
- Correction performance: time from changed fact to reviewed update; accurate references; superseded text preserved; unauthorized corrections blocked; active message identifiable.
- Resilience and accountability: access violations, connector failures, retries, and actions attributable; deterministic replay; recovery exercised; material gaps visible.
Retain the baseline, source fixtures, expected results, model and adapter versions, validations, authorizations, channel responses, reviewer decisions, timings, exceptions, and evaluator notes as evaluation receipts. Set thresholds before the run; a missed safety, authority, or provenance threshold fails the evaluation.
Keep evidence levels explicit. Official-source analysis supports a research-grounded claim about the problem and institutional boundaries. A passing fixture may support a product-demonstration claim for its sources, rules, failures, and adapters. A customer-controlled claim requires the responsible organization to control material inputs, cases, environment, operators, or acceptance conditions; claims about intended use require evidence from the intended environment. None alone proves legal compliance, live delivery, understanding, emergency availability, or improved outcomes.
Teams can map one revision through From a Changed Fact to Coordinated Action, apply the authority boundary in AI Can Propose. Who Authorizes?, and record the baseline and receipts in the decision evaluation worksheet. Grid Developers provides implementation-oriented guidance for explaining and validating a changing decision and canonical examples.
The goal is accountable speed: an inspectable event basis, human and scoped authority, channel-specific state, and corrections connected to what they change. The model does not create trust by declaration. It provides a bounded test of whether responsibility survives urgency.
Related films, scenarios, and next steps
Continue exploring
Follow the next question.
Authorize and Correct a Public Warning Across Evidence, Channels, and Jurisdictions
Connect incident evidence, scoped public-warning permissions, exact-message authorization, channel-specific receipts, and versioned corrections without treating technical acceptance as public receipt or a model as warning authority.
Understand · GovernSource-grounded ExploreHow Grid Works: From Typed Facts to Accountable Action
A technical and operational guide to the six-stage Grid chain: governed sources, a shared and versioned model, reactive constraint evaluation, coordinated surfaces, explanation and evidence, and AI assistance bounded by human authority.
Understand · EvaluateSource-grounded ExploreHow to Evaluate Executable Decision Infrastructure
A buyer's guide for turning a compelling demonstration into a bounded evaluation of sources, logic, explanations, authority, interoperability, change behavior, and evidence.
Evaluate · PlanSource-grounded Explore