The previous chapters defined what a WIA-ENE-033 system exchanges (observation, prediction and alert objects), how it is called (the /api/v1/... interface) and how it decides (the forecasting and alert protocol). This chapter is about where those pieces run and who connects to them: the three integration patterns named in PHASE-4, the external systems described in PHASE-2 §12.1, the four reference topologies of Annex J, and the security, privacy and availability measures a flood-warning service needs before it can be trusted with a real river.
A flood-forecasting system is almost never a single application. It sits between organisations that own gauges and dams, a meteorological service that owns rainfall radar and numerical weather prediction, a disaster-management authority that owns the legal power to warn the public, and municipalities that own drainage pumps, shelters and road closures. The integration design therefore decides much of the system's real-world value: a forecast that is correct but reaches the warning officer twenty minutes late, or a warning that is issued but cannot be verified as authentic, fails at the moment it matters. The sections below keep that end-to-end view in mind.
PHASE-4 names three integration patterns and states that each is supported by the manifest mechanism described in PHASE-1 and the interoperability profiles of Annex I. They differ less in technology than in the position an operator occupies in the flow of water and of information.
In the first pattern a single national operator runs the forecasting service and federates provincial or regional gauge networks. The provincial networks keep ownership of their stations and field maintenance; the national node receives their observations, runs basin-scale and nationwide models, and publishes forecasts. The main integration challenges are heterogeneity (different station vendors, logging intervals and datums inherited from decades of separate procurement) and governance (who may change a threshold in RiverLevelData.levels for a station the national node does not own). An implementation in this pattern typically supports all five operation groups of PHASE-2: gaugeIngest, forecastQuery, warningPublish, simulationSubmit and evacuationRoute.
The second pattern is a regional operator organised around a catchment rather than an administrative boundary. It aggregates observations from several upstream owners (the national network, dam operators, provincial gauges), runs a basin forecasting node, and publishes forecasts and warnings to downstream municipalities. Because water ignores administrative lines, this pattern is often the most natural unit for river forecasting: the travel time from an upstream gauge to a downstream town is a property of the basin, and so is the effect of a dam release plan (DamStatusData.dischargePlan) on stages further down.
The following diagram shows the river-basin pattern with the ENE-033 operation group that governs each hop.
UPSTREAM OWNERS BASIN AUTHORITY DOWNSTREAM
─────────────── ─────────────── ──────────
Gauge network A ──┐
(RiverLevelData) │ gaugeIngest
Gauge network B ──┼──────────▶ ┌──────────────────────┐
│ │ Basin forecasting │ forecastQuery
Dam operator ──┤ │ node │ ─────────────────▶ Municipality 1
(DamStatusData) │ │ - ingest / QC │ (city EWS)
│ │ - 1D / 2D / AI models│
Met service ──┘ │ - ensemble │ warningPublish
(PrecipitationData, └──────────┬───────────┘ ─────────────────▶ Municipality 2
radar) │ CAP 1.2 feed +
▼ WIA-native envelope
┌──────────────────────┐
│ Warning publisher │ ─────────────────▶ National public-
│ (FloodAlert, CAP 1.2) │ warning channels
└──────────────────────┘Two properties of this pattern deserve attention. First, the basin authority is both a consumer (of upstream data it does not control) and a producer (of forecasts others rely on); its interoperability profile must declare both directions honestly. Second, the warning feed is the contract with downstream municipalities. PHASE-2 requires that warningPublish emit CAP 1.2 in addition to the WIA-native envelope, so a municipality whose public-warning system already understands CAP needs no custom adapter to receive the basin's warnings.
The third pattern is a municipal operator. It subscribes to upstream forecasts (from a national service or basin authority) and adds a local model for urban, or pluvial, flooding: the rain that overwhelms sewers and pumps before any river overtops. Here the city's own assets matter most: DrainageData for pump stations, sewers and detention basins, EvacuationShelter and EvacuationRoute data, and links to traffic control. A city system rarely needs gaugeIngest for major rivers, but it does need it for its own sewer-level and basin sensors.
| Aspect | National hydrological service | River-basin authority | City-level EWS |
|---|---|---|---|
| Operator scope | Whole country, federated provinces | One catchment across several administrations | One municipality |
| Main inputs | Provincial gauge networks, national radar, dams | Upstream gauges, dam release plans, meteorological forecasts | Upstream forecasts, local rainfall, drainage sensors |
| Main outputs | National forecasts and warnings | Basin forecasts, CAP warning feed to municipalities | Local warnings, shelter and route status |
| Dominant flood types | River, flash | River (with dam influence) | Urban (pluvial), plus river where applicable |
| Typical operation groups | All five | gaugeIngest, forecastQuery, warningPublish, simulationSubmit | forecastQuery (as client), warningPublish, evacuationRoute |
| Likely Annex J topology | Federated mesh or multi-tenant gateway | Federated mesh | Single-tenant edge |
The last row is a starting point, not a rule. Annex J states that its topologies are non-normative and that it does not recommend against alternatives. A small basin authority may reasonably run a single-tenant edge deployment and exchange data with its neighbours by subscription.
PHASE-2 §12.1 describes the external connections as a TypeScript interface called SystemIntegration. It is reproduced here because it is the only place in v1.0 that lists the classes of external systems a deployment is expected to connect.
interface SystemIntegration {
weatherService: {
apiEndpoint: string;
dataTypes: ['precipitation', 'forecast', 'radar'];
updateInterval: number; // minutes
};
hydrologicalNetwork: {
stations: number;
protocols: ['MQTT', 'HTTP', 'WebSocket'];
dataFormats: ['JSON', 'XML', 'CSV'];
};
emergencySystem: {
alertBroadcast: boolean;
situationRoom: boolean;
resourceManagement: boolean;
};
smartCity: {
trafficControl: boolean;
infrastructureMonitoring: boolean;
citizenServices: boolean;
};
}Read literally, the array members such as ['MQTT', 'HTTP', 'WebSocket'] are TypeScript tuple types, which would require every deployment to list all three protocols in that order. That is almost certainly not the intent. This book reads them as the set of permitted values: a deployment declares the subset it actually supports, for example a hydrological network that accepts only MQTT and CSV. When you generate a machine-readable description of your integration, express these as enumerations, not tuples.
The weather service supplies observed and forecast precipitation and radar products. In ENE-033 these land in PrecipitationData: observed accumulations, forecast accumulations and the optional radar block. The updateInterval field (minutes) matters for two reasons. It bounds how fresh a forecast can be, and it lets the forecasting node detect a stalled feed: if no new precipitation product has arrived within, say, twice the declared interval, the node should flag reduced input quality rather than silently reuse the last product. The factor of two is an illustrative choice, not a value from the specification.
The hydrological network delivers gauge observations. PHASE-2 names MQTT, HTTP and WebSocket as transports and JSON, XML and CSV as formats. In practice a deployment often receives XML in OGC WaterML 2.0 from a national archive, CSV from older data loggers and JSON or MQTT payloads from newer telemetry. The integration layer's job is to normalise all of them into RiverLevelData and DamStatusData with explicit units and UTC timestamps, as described in Chapter 2.
One gap must be stated plainly. PHASE-2 defines a gaugeIngest operation group, but the reference TypeScript SDK exposes no ingest endpoint; its monitoring methods only read data. A deployment that must accept observations from third-party owners therefore has to build its own ingest adapter, ideally one that validates payloads against the Chapter 2 schemas before accepting them and records the source, the arrival time and any unit conversion it applied.
The emergencySystem block has three booleans: alertBroadcast (can the deployment hand alerts to public broadcast channels), situationRoom (does it feed a disaster situation room) and resourceManagement (does it exchange data on resources such as shelters, pumps or crews). The broadcast link is the most sensitive integration in the entire system, because it turns a software decision into a message on millions of phones. Section 6.5 covers how to protect it.
In Korea, public flood forecasts (홍수특보) are issued by the flood control offices, and national disaster-response levels follow a separate framework. An ENE-033 system that connects to these channels acts as a decision-support and distribution component; it does not take over the legal authority to issue official forecasts. The alert objects must carry the issuer (FloodAlert.issuer with organizationId, name and authorityLevel) so that recipients can tell whose warning they are reading.
The smartCity block covers traffic control, infrastructure monitoring and citizen services. The strongest use case is evacuation routing: when a road segment floods, the city's traffic system and the ENE-033 EvacuationRoute objects (with FloodedSegment and RouteStatus) should agree. A route that the warning tells people to use but that traffic control has closed is worse than no route at all.
| External system | Direction | ENE-033 objects involved | Typical transport and format |
|---|---|---|---|
| Weather service | In | PrecipitationData (observed, forecast, radar) | HTTP pull; gridded or JSON products |
| Hydrological network | In | RiverLevelData, DamStatusData | MQTT or HTTP; JSON, WaterML 2.0 XML, CSV |
| Municipal drainage SCADA | In | DrainageData | Gateway export; JSON or CSV |
| Emergency system | Out (and status back) | FloodAlert, CAP 1.2, delivery counts | CAP 1.2 XML over HTTP; WIA-native JSON |
| Smart-city platform | Both | EvacuationRoute, EvacuationShelter, MonitoringDashboard | HTTP or WebSocket; JSON |
A declared integration for a city-level system might look like the following. The endpoint and numbers are examples only.
{
"weatherService": {
"apiEndpoint": "https://met.example.org/api/precip",
"dataTypes": ["precipitation", "forecast", "radar"],
"updateInterval": 10
},
"hydrologicalNetwork": {
"stations": 42,
"protocols": ["MQTT", "HTTP"],
"dataFormats": ["JSON", "CSV"]
},
"emergencySystem": {
"alertBroadcast": true,
"situationRoom": true,
"resourceManagement": false
},
"smartCity": {
"trafficControl": true,
"infrastructureMonitoring": true,
"citizenServices": false
}
}Annex J (published identically in all four PHASE documents) describes four reference topologies that the working group used to validate its test vectors. They answer a different question from the integration patterns: not whom you connect to, but how runtimes, tenants and conformance manifests are arranged.
| Topology | Shape | Manifest and signing | Fits when | Watch out for |
|---|---|---|---|---|
| Single-tenant edge | One runtime per organisation, no shared state | Organisation signs its own manifest; evidence published manually | Pilots; a single city or small basin | Manual evidence tends to go stale; single point of failure unless made redundant |
| Multi-tenant gateway | One shared runtime; tenants isolated by headers behind a rate-limited gateway (for example Envoy or NGINX) and a shared identity provider | Per-tenant manifests plus a federation manifest aggregating them | A national service hosting provinces; a vendor hosting several cities | Tenant identity must come from the verified token, never from a header the client sets |
| Federated mesh | Several runtimes peer and publish manifests to a directory service | Each peer signs its own; directory signs the aggregated index | Basin authorities and cross-organisation exchange | Profile mismatch between peers; directory availability |
| Air-gapped batch | No live link between runtime and directory; signed evidence packages carried out of band | Signed package per batch | Regulators or sites that prohibit live connectivity | Suits evidence and archives, not live warnings |
Three remarks keep these topologies honest in a flood context.
The Annex J text for the multi-tenant gateway refers to an "OAuth 2.1 identity provider." OAuth 2.1 is, at the time of writing, an IETF draft that consolidates OAuth 2.0 and its security best practice; it is not yet a published RFC. Section 6.5 returns to this point.
The README proposes four implementation stages. The durations it gives (one to two months, two to three months, one to two months, then ongoing) are indicative only; real timelines depend on how many gauges already exist, how clean the historical record is and how long procurement and legal agreements with data owners take. It is more useful to treat each stage as a set of exit criteria.
| Stage | Work items (from README) | Suggested exit criteria |
|---|---|---|
| 1. Data collection infrastructure | Install and connect water-level sensors; connect rainfall radar; connect dam management system; build real-time data pipeline | Every station has a documented datum, unit and time source; payloads validate against the Chapter 2 schemas; missing data is recorded as missing, not as zero; data owners have signed usage agreements |
| 2. Prediction model development | Collect historical flood data; train AI model; build inundation simulation; validate and tune accuracy | Hindcast evaluation on events held out of training, reported with POD, FAR and CSI (Chapter 5); model versions recorded; results reproducible from archived inputs |
| 3. Warning system | Set alert criteria per risk level; multichannel alerts (SMS, app, siren); evacuation-route optimisation; link to emergency response protocols | CAP 1.2 output validates; role separation in place (Section 6.5); end-to-end test from forecast to a test recipient group; cancellation path tested |
| 4. Operation and improvement | Real-time monitoring and response; continuous accuracy improvement; resident evacuation drills; expansion | Monthly error-budget report (Section 6.7); post-event reviews recorded in FloodResponseReport; evidence package re-published quarterly (Chapter 7) |
This book recommends two ordering rules. First, do not start Stage 3 before the Stage 1 exit criteria are met: an alerting system built on unreliable data teaches the public to ignore it. Second, run the warning chain in a shadow mode, with alerts routed only to staff, through at least one wet season before connecting public channels. The length of the shadow period is a local decision; the specification does not set one.
PHASE-4 §13.1 lists four security measures: encryption in transit with TLS 1.3 and at rest with AES-256, role-based access control (RBAC), authentication with OAuth 2.0 plus multi-factor authentication, and audit logs for all important operations. PHASE-4 cites ISO/IEC 27001:2022 (information security management systems) and ISO/IEC 27018:2019 (protection of personal data in public clouds acting as processors) as the management-system context. These are reasonable baselines, but a flood-warning system has a threat profile that deserves more specific treatment.
Version 1.0 describes authentication in three different ways. PHASE-2 says OAuth 2.1 with mTLS for institutional callers and cites RFC 9700; RFC 9700 is in fact the OAuth 2.0 Security Best Current Practice, not an OAuth 2.1 specification. PHASE-4 says OAuth 2.0 plus MFA. The reference SDK sends a static bearer API key in the Authorization header together with X-WIA-Standard: ENE-033 and X-WIA-Version: 1.0.0.
A coherent reading, and the one this book recommends, is as follows. Machine-to-machine calls between institutions (a basin node pulling from a national node, a municipality subscribing to a warning feed) use mutual TLS plus OAuth 2.0 client credentials following the RFC 9700 best practice. Human operators log in through the identity provider with MFA. Static API keys are acceptable only for read-only, low-risk clients such as a public dashboard, and never for any role that can publish a warning.
PHASE-4 requires RBAC but does not define roles. The following role set is a suggestion that follows the separation of duties in the forecast-to-warning chain. Endpoint paths are those of the reference SDK (Chapter 4).
| Role | Purpose | Allowed | Not allowed |
|---|---|---|---|
| Observer | Read status for situation awareness (partner agencies, public dashboard back end) | GET /monitoring/*, GET /alert/active, GET /alert/{id} | Any write; access to recipient lists |
| Forecaster | Run and review predictions and simulations | Observer rights; POST /flood/predict, POST /flood/simulation, GET /flood/* | POST /alert/create, alert update or cancel |
| Warning officer | Issue, update and cancel alerts under the operator's legal mandate | Observer rights; POST /alert/create, PUT /alert/{id}/update, POST /alert/{id}/cancel, shelter status updates | Changing model configuration or station thresholds |
| Auditor | Verify after the fact | Read-only access to audit logs, /analytics/*, evidence packages | Any operational write |
| Integration service (machine) | Ingest observations from a specific data owner | Ingest for its own stations only | Reading other owners' raw data; alert endpoints |
The split between forecaster and warning officer is deliberate. It mirrors the manualReview branch of AlertCriteria described in Chapter 5: when uncertainty is high, critical infrastructure is involved or the event is historically significant, a human with authority decides. That authority should be a distinct role that the forecasting software cannot assume on its own.
The most damaging attack on a flood-warning system is not data theft but a false or suppressed warning. A forged "evacuate now" alert causes panic and erodes trust; a suppressed or silently cancelled one costs lives. The following controls address that risk directly.
/alert/create, /alert/{id}/update or /alert/{id}/cancel. Automatic issuance under AlertCriteria.automatic should run under a dedicated service identity whose actions are logged exactly like a human's.FloodAlert.issuer.SensorStatus.An audit record for an alert action might contain the following fields. The layout is illustrative; PHASE-4 only requires that important operations be logged.
{
"eventId": "AUD-2026-000317",
"timestamp": "2026-07-14T05:42:10Z",
"actor": { "subject": "officer-0192", "role": "warning-officer", "mfa": true },
"action": "alert.create",
"target": { "alertId": "ALERT-2026-000041", "level": "LEVEL-3" },
"basis": { "predictionId": "PRED-2026-000118", "decision": "manualReview" },
"clientCert": "sha256:9f2c...e1",
"result": "accepted"
}PHASE-4 §13.2 commits to compliance with the GDPR and Korea's Personal Information Protection Act (개인정보 보호법), to minimal collection, to no use beyond the stated purpose and to limited retention. The ENE-033 objects themselves carry little personal data, but the systems around them do. The table below identifies where it enters.
| Data element | Personal? | Minimisation measure |
|---|---|---|
inundationArea.affectedPopulation, AffectedAreas.population | No, if computed as an aggregate count | Compute from census grids or zone totals; never store the list of individuals behind the number |
AlertDistribution.recipients (highRisk, vulnerable, firstResponders, publicOfficials, general) | Yes (phone numbers, device tokens, e-mail addresses) | Keep in the distribution service only; reference groups by ID in ENE-033 objects; the vulnerable group reveals sensitive circumstances and needs the strictest access |
Shelter occupancy (EvacuationShelter capacity and status) | No as counts; yes if check-in registers are kept | Publish counts only; keep any name registers in the shelter-management system with separate retention |
RegionStatus.evacuationProgress | No (percentage) | Derive from aggregates; avoid tracking individual devices to compute it |
| Audit logs | Yes (operator identities) | Restrict to the auditor role; retain per local law |
On retention, the Annex E notes, repeated in all four PHASE documents, state that a seven-year window "is sufficient to satisfy ISO/IEC 17065:2012 audit expectations in most jurisdictions." ISO/IEC 17065 sets requirements for bodies certifying products, processes and services; it does not prescribe a seven-year period. Retention periods should instead be set from the applicable law and the operator's records policy, and they will differ between operator audit logs (which must outlive post-event inquiries) and recipient contact data (which should be kept no longer than the subscription).
A useful design rule is that personal data should never be needed to forecast; it is needed only to deliver. Keeping that boundary in the architecture, with forecasting nodes that hold no recipient data, shrinks both the privacy risk and the scope of any breach.
The README lists four stability measures (redundant servers, automatic failover, backup power and a disaster recovery plan) and four warning-reliability measures (multichannel delivery, delivery confirmation, priority-based transmission and an offline backup system). A flood-warning service has an unusual availability profile: its peak demand coincides with the conditions most likely to break it, including power cuts, flooded equipment rooms and congested mobile networks.
inundationArea outputs for worst-case scenarios.SensorStatus.offline) the forecasting node should keep running with reduced confidence rather than stop. When the forecasting node itself is down, warning officers must still be able to issue manual alerts through the warning publisher. When the publisher is down, a pre-agreed offline backup, such as a direct procedure with the broadcast authority, takes over.AlertDistribution.status counts sent, delivered, failed and confirmed. A rising failed count on one channel during an event is an operational signal to shift priority to other channels (siren, radio, TV).Every observation, forecast and alert carries an ISO 8601 UTC timestamp, and the time-to-overflow and lead-time calculations of Chapter 5 are differences between timestamps. The Annex E notes state that NTPv4 against stratum-2 servers is sufficient for most deadlines, with the Precision Time Protocol (IEEE 1588) recommended where deterministic interlocks are required. For field loggers that cannot run NTP continuously, record the clock offset at each synchronisation so that the ingest layer can correct or flag drift.
The README sets system availability of 99.9 % or more as a design target. It is worth turning such a target into minutes: over a 30-day month, 0.1 % unavailability is 43.2 minutes. Whether that budget is acceptable depends on when the minutes are spent; the same outage is harmless in a dry week and serious during a storm. Operators should therefore report availability both overall and for periods when any region was at LEVEL-2 or above.
Annex E recommends a monthly error-budget summary with p95 latency, error rate and violation hours, published without tenant-specific data. A report might look like the following; the numbers are examples.
{
"period": "2026-07",
"service": "basin-forecast-node",
"availability": { "overall": 99.95, "duringLevel2Plus": 99.99 },
"latencyP95Ms": { "forecastQuery": 420, "alertCreate": 180 },
"errorRate": 0.0021,
"violationHours": 0.5,
"notes": "30-minute radar feed gap on 2026-07-14; forecasts ran with reduced confidence"
}The live counterpart of this report is the MonitoringDashboard.system block (uptime, latency, dataQuality, errors) together with sensors (total, active, offline, maintenance). The monthly report and the conformance evidence of Chapter 7 are the two views an external auditor will read; they should be generated from the same logs so that they cannot disagree.
Among the README's operational work items are resident evacuation drills. The technical system should take part in them: run a drill alert end to end through a clearly marked test channel, measure the time from decision to delivery, and exercise at least one failover path. A failover that has never been exercised should not be counted as available.
gaugeIngest must be built by the deployment.Chapter 7 turns to how an implementation proves all of this to someone else: test vectors, evidence packages, interoperability profiles and the two conformance vocabularies found in v1.0.