Standards and interoperability

Adopted standards

ClimaHub alerts are published using the OASIS Common Alerting Protocol (CAP) version 1.2, the international format for public warning exchange used by meteorological services and civil protection systems. Publication happens through two public, unauthenticated endpoints:

https://climahub.dumontdev.com.br/cap/feed.xml — Atom feed with the alerts currently in force application/atom+xml
/cap/alerta/{identifier}.xml — CAP 1.2 document for an alert currently in force (live example) application/cap+xml

Each document is serialized following the element sequence required by the official OASIS schema, and the project's test suite validates generated documents against that schema (XSD), which is versioned in the repository.

Official schema (OASIS): docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2.xsd

SHA-256 of the XSD versioned in the project:
b7798ef25868b068c97b268bda02d067c7d4ba9373adc5638bf37105804ee723

In this demonstration instance, published alerts carry <status>Exercise</status> — the semantics CAP itself prescribes for exercises — and are visually labelled as simulations on the public panel.

Alert life cycle

ClimaHub treats an alert as a document with a validity period and an audit trail, not as an editable post:

Mandatory validity: No alert exists without an expiration time (expires). The form suggests a duration based on the event type; the operator may adjust it — never omit it.
Automatic expiration: The "active alert" condition is evaluated by query on every request — an expired alert disappears from the panel and the feed immediately, with no dependency on background jobs. A periodic process records the transitions for historical purposes.
Update and cancellation: Corrections are published as new messages (msgType Update) and early terminations as cancellations (msgType Cancel), always referencing the original message (references) in the standard's format. The superseded message leaves the in-force list.
Immutability: An issued alert can be neither edited nor deleted. A correction is a new message chained to the previous one — an audit requirement in emergency communication.
Official-issuance lock: Until the instance is accredited by a civil defence authority, issuing official alerts (status Actual) is blocked at the application's data layer, not merely in the user interface.

Interoperability roadmap

Current and planned state of integrations. Labels reflect what exists today: "In production" means functionality that is operating and verifiable on this instance; "Planned" means an intended integration with no implementation yet.

Integration	What it adds	Status
OASIS CAP 1.2	Alert dissemination in the international standard format (public Atom feed + XML documents conforming to the official schema), consumable by aggregators and applications.	In production
OpenWeatherMap	Current weather conditions and 5-day forecast for the municipality, feeding the panel and the internal risk assessment.	In production
CEMADEN	Brazil's national rain-gauge network and geo-hydrological risk alerts — primary input for anticipating landslides and flash floods.	Planned
INMET	Official meteorological stations and severe-weather advisories, complementing forecasts with observational data.	Planned
ANA / SNIRH	River-gauge series and water levels for rivers and channels — essential for flood warning in lowland municipalities such as Pelotas.	Planned
SGB-CPRM	Susceptibility charts and hydrological monitoring from the Geological Survey of Brazil, to qualify risk areas.	Planned
S2iD	Brazil's Integrated Disaster Information System — aligning the municipal occurrence registry with the federal disaster-recognition workflow.	Planned

The sensor-data ingestion layer (sources, readings, data quality and network health) is specified in the project architecture and will be built before the first integrations, so that public networks and the municipality's own sensors share a single data model.

Deployment model

ClimaHub runs as one instance per municipality: the IBGE geocode (Pelotas/RS — 4314407), the reference coordinates and the issuing-authority identification are instance configuration, not per-record data. This choice simplifies operations, data isolation and individual accreditation. Evolution towards multiple municipalities in a single instance is mapped — it would require a municipalities entity, territorial scoping of queries and per-municipality CAP feeds — and will be evaluated according to deployment demand.

Personal data protection

No personal data flows through the public panel or the CAP feed: public routes expose only alerts, non-attributable georeferenced occurrences and operational shelter information. Records of affected people — which may contain sensitive data — are restricted to authenticated users with the appropriate role. Processing follows Brazil's LGPD as the normative reference (and the GDPR for international cooperation); a public data-protection policy, covering legal basis, data categories, purposes and retention periods, is part of the project's evolution roadmap.