> For the complete documentation index, see [llms.txt](https://standards.spdci.org/standards/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://standards.spdci.org/standards/dci-standards/early-warning-systems/wip-early-warning-systems-and-sp-system-interface/9.-ews/1.2-process/prs.ews.01-ews-notify-sp-system-for-anticipatory-action.md).

# PRS.EWS.01: EWS notify SP System for anticipatory action

The aim of the process [PRS.EWS.01: EWS notify SP System for anticipatory action](/standards/dci-standards/early-warning-systems/wip-early-warning-systems-and-sp-system-interface/9.-ews/1.2-process/prs.ews.01-ews-notify-sp-system-for-anticipatory-action.md) Early Warning Notification to Social Protection Systems for Anticipatory Action process is to support the timely activation of anticipatory actions through the integration of Early Warning Systems (EWS) and social protection systems. It can be implemented during preparedness, monitoring, or emergency response stages to enable social protection institutions to take early measures before the anticipated hazard impacts affected populations.

This process enables the exchange of hazard-related information and geographic risk data necessary for social protection systems to assess potential impacts on registered beneficiaries and vulnerable populations. Depending on the country context and anticipatory action framework, the process can be implemented independently or in combination with additional processes related to beneficiary verification, targeting, case management, notification delivery, or assistance disbursement.

The actual anticipatory actions triggered through this process are dependent on national policies, operational procedures, and hazard-specific anticipatory action protocols. These actions may include cash assistance, accessible warning dissemination, evacuation support, livelihood protection measures, relief pre-positioning, emergency enrollment or referrals to complementary support services.

The Data Standards section outlines the different data elements that may be shared as part of the notification process depending on operational requirements and available information. These options may include sharing hazard event details alone, such as hazard type, severity, forecast period, and affected geographic locations.

{% hint style="info" %}
**Interoperability Governance & Data Precedence**\
\
System architects and implementing teams must design the data interface to cleanly ingest all incoming warning and response messages, leaving legal mandates and country-specific governance rules entirely outside the data payload layers. When multiple messages overlap for the same geographic area and time window, the system should simply organize and present the conflicting data clearly—anchored by sender ID and timestamps—rather than blocking the stream or enforcing automated system-level drops. This architecture allows the human operators managing the social protection intervention to easily interpret the data stream, apply testable verification workflows, and safely decide how to intervene based on their internal institutional mandates.
{% endhint %}

 


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://standards.spdci.org/standards/dci-standards/early-warning-systems/wip-early-warning-systems-and-sp-system-interface/9.-ews/1.2-process/prs.ews.01-ews-notify-sp-system-for-anticipatory-action.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.