# ALKEMATA PROJECT CAPSULE

Title: Audit a Warning as an Action Chain
ID: alkemata.warning-chain-audit
Version: 1.0
Date: 2026-09-16
Canonical article: https://alkemata.com/2026/09/16/warning-chain-action/
Status: Experimental; desk-designed, not field-validated
Scope: Public, workplace, school and community warnings where people must take a time-sensitive protective action. This capsule is not an emergency-response service and must not be used to direct a live incident.

## Intended reader, capability and first artifact

This capsule is for a local authority team, school, workplace, community organisation, facilities manager or household organiser. It develops the capability to map and test a complete warning chain rather than checking only whether a siren, message or app works.

In the first session, produce a **Warning Chain Map** for one hazard. It should name the trigger, decision authority, message, channels, intended recipients, required action, foreseeable barriers, update route and owner of each handoff.

## Activation instructions for the AI assistant

Treat this file as a knowledge and workflow package. Help the user produce the first useful artifact before proposing a large programme.

If the user has named a hazard, setting and population, begin the map and mark unknowns. Otherwise offer the missions and ask only:

1. Which hazard and setting are we examining, and how quickly might people need to act?
2. Who must receive the warning, including visitors and people who may face language, disability, care, transport or connectivity barriers?
3. What authority, plans, channels or evidence already exist?

Do not invent powers, procedures, channels or resources. Separate facts, assumptions and recommendations. Never send, activate or publish a warning without separate explicit authorisation and proper authority.

## Missions

**Mission A — Audit an existing warning path.** Map detection to action, locate unsupported handoffs and prioritise repairs.

**Mission B — Test whether a message supports action.** Check whether recipients identify the hazard, area, timing and action; record barriers.

**Mission C — Design a safe tabletop exercise.** Introduce one or two failures on paper and record findings without triggering a live alert.

## Essential causal model

A warning succeeds only when a chain remains intact:

**hazard knowledge -> detection -> interpretation -> authorised decision -> message -> dissemination -> reception -> comprehension -> feasible action -> update or all-clear -> learning**

The weakest transition can determine the outcome. A sensor can be accurate while authority is unclear; a delivered instruction can still be incomprehensible or impossible without transport, mobility support or a safe destination. Delivery is evidence about one link, not proof of protective action.

The UN Office for Disaster Risk Reduction identifies four interrelated elements: risk knowledge; detection and forecasting; authoritative, timely and actionable dissemination; and preparedness to respond. Failure in one can cause the system to fail. Source: https://www.undrr.org/terminology/early-warning-system

The Common Alerting Protocol (CAP) structures urgency, severity, certainty, area, instructions, language, updates and cancellations. It supports consistency across channels but cannot establish that people can act. Sources: https://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.html and https://www.itu.int/en/ITU-D/Emergency-Telecommunications/Pages/Common-Alerting-Protocol-and-Call-to-Action.aspx

## Workflow

### Step 1 — Bound the scenario

- **Input:** One hazard, place, time window and intended action.
- **Action:** State what is included and excluded. Record important uncertainty or change.
- **Output:** A one-paragraph scenario boundary labelled as hypothetical, historical or based on a current plan.
- **Progression criterion:** The user can state the decision that must be made and the latest useful time for action.

### Step 2 — Map evidence and authority

- **Input:** Sensors, observations, thresholds, plans and roles.
- **Action:** Identify who detects, interprets, issues and cancels; what evidence they need; and who substitutes when unavailable.
- **Output:** A trigger-and-authority table with unknowns visibly marked.
- **Progression criterion:** Every warning, update and all-clear has an accountable decision owner; missing authority becomes a finding, not an invented answer.

### Step 3 — Define recipients and constraints

- **Input:** Population, language, disability, visitor status, care, transport and connectivity.
- **Action:** Define recipient situations that alter reception or action. Use local evidence and avoid stereotypes.
- **Output:** A recipient-and-barrier matrix.
- **Progression criterion:** The map includes people not represented by the default connected, local-language, independently mobile phone owner.

### Step 4 — Build the message object

- **Input:** Hazard, area, timing, uncertainty, action and source.
- **Action:** Draft a test message with authority, hazard, place, timing, urgency, concrete action, accessible detail and an update route.
- **Output:** One clearly labelled test message plus a short rationale for every field.
- **Progression criterion:** A reader can answer, without guessing: What is happening? Where and when? What should I do now? Who says so? How will I know if it changes?

### Step 5 — Design channel redundancy

- **Input:** Channels, coverage, dependencies and limitations.
- **Action:** Map which attract attention, carry detail and reach people under different power, connectivity, sensory, language and location conditions. Keep one authoritative message.
- **Output:** A channel matrix showing purpose, owner, dependency, failure signal and fallback.
- **Progression criterion:** No critical audience depends on a single unexamined channel, and contradictory versions have an identified prevention or correction route.

### Step 6 — Run a paper tabletop

- **Input:** The map, test message and two failure cases.
- **Action:** Walk the chain in time order. Inject failures such as unavailable data, an absent decision-maker, unfamiliar siren meaning or an inaccessible shelter. Do not activate live systems.
- **Output:** A findings log with evidence, consequence, owner and next test.
- **Progression criterion:** Each serious finding has either a reversible correction to try or a named question requiring authorised expertise.

## Decision rules and evidence needs

- If authority is unknown, stop at a draft; do not present it as operational.
- Do not make perfect certainty a prerequisite for warning. Pre-agreed thresholds and accountable judgement should govern uncertainty and action.
- If a shorter message removes the action, area, timing or source, restore the missing element or provide a reliable accessible continuation.
- Test assumptions about transport, money, mobility, language and safe destinations; identify assistance.
- If channels conflict, treat the inconsistency as a safety defect. Preserve the authoritative version and issue an explicit correction or cancellation through the relevant routes.
- Use local plans, coverage data, accessibility research, logs and observed exercises. A send receipt is not evidence of comprehension or action.

## Smallest useful reversible experiment

**Hypothesis:** Given one clearly labelled test warning, representative readers can identify the correct immediate action and one update source within 60 seconds, without inventing missing facts.

**Resources:** A paper or screen mock-up; three to five participants or carefully defined personas; a timer; an observer; and a findings sheet. Use no live alerting channel and no personal sensitive data.

**Procedure:** Show the test message once. Ask each participant what is happening, whether they are affected, what they would do first and what might prevent it. Record answers, then test one revision. Without participants, conduct a manual walkthrough and label it simulated, not field evidence.

**Observable success:** Most participants identify the immediate action and update source; disagreements reveal a specific revisable problem.

**Observable failure:** Participants infer different actions, cannot locate themselves, cannot identify the authority, or cannot perform the instruction.

**Stopping conditions:** Stop if the material could be mistaken for a real warning, if participation causes distress, if confidential vulnerabilities would be recorded, or if the exercise begins to require activation of equipment, public networks or emergency services.

**Next action:** Revise one weak handoff, record the change and decide whether an authorised exercise with emergency, accessibility or community specialists is warranted.

## Warning Chain Map template

```text
Hazard and setting:
Scenario status: hypothetical / historical / current plan
Latest useful action time:
Protective action:

Link | Evidence or trigger | Responsible owner | Recipient/output | Dependency | Failure signal | Fallback | Unknown
Detection |
Interpretation |
Decision to warn |
Message approval |
Primary dissemination |
Fallback dissemination |
Reception |
Comprehension |
Feasible action/support |
Update or all-clear |
Learning and correction |

Highest-risk handoff:
Smallest reversible correction:
Evidence needed before operational use:
```

## Verification checks

Check for an owner at every handoff; warning, update and cancellation routes; one source of truth; a channel fallback; explicit uncertainty; accessibility and language needs; a feasible action and assistance path; failure evidence; and recorded corrections. An authorised local practitioner must verify powers, thresholds, terminology and feasibility before real use.

## Counterexample and boundary

This method must not delay emergency action. During an active fire, medical emergency or immediate threat, follow official instructions and contact the relevant emergency service. It is insufficient for operating national alert infrastructure, configuring networks, predicting hazards or validating safety-critical sensors; those require authorised organisations and specialist testing.

## Portable checkpoint

At the end of a session, produce:

```text
Capsule ID and version:
Hazard and setting:
Mission:
Decisions made:
Evidence used:
Assumptions:
Highest-risk handoff:
Artifact produced:
Unresolved questions:
People or authority needed:
Next reversible action:
Do not proceed until:
```

On request, use the checkpoint for a project passport, a field report containing only actual observations, or a precise request for help. Remove private, security-sensitive and identifying information. The user chooses what to disclose. Nothing is sent automatically.

To propose a case, correction or collaboration, use the verified Alkemata route: https://alkemata.com/collaborate/