The previous seven chapters described WIA-ENE-033 as it stands in version 1.0: what it models, how it is called, how it decides, how it is deployed and how conformance is proven. This final chapter looks forward. It separates what the standard's own documents actually commit to for the next version from what the wider field of flood forecasting is moving towards, and it is explicit about the limits that any adopter should keep in view, including the limits of automation itself.
Forecasting chapters about "the future" are easily filled with projections that nobody can check. This chapter deliberately avoids that. The only forward commitments quoted here come from the release notes and the Annex F adoption roadmaps of the four PHASE documents. Everything else is labelled as either a direction in the field, a gap observed in v1.0, or this book's own recommendation. The distinction matters: an implementer who plans a procurement around a feature must know whether it is promised, merely plausible, or only suggested.
The release notes for v1.0 (status: Stable) list exactly two known limitations. First, flood-inundation models that depend on lidar-derived digital elevation models (DEMs) with a horizontal resolution finer than 1 m are out of scope. Second, storm-surge coupling "is documented as a roadmap item for v1.1". These two sentences are the whole of the published technical roadmap. Note the asymmetry: storm-surge coupling is explicitly scheduled for v1.1, while sub-metre inundation is only declared out of scope, with no version named. An adopter should not assume that both arrive together.
The FloodEventType enumeration already contains coastal-flood, and a FloodAlert can carry event.type: "coastal-flood". What v1.0 lacks is any protocol for bringing the sea into the forecast. The observation model of Chapter 2 has objects for precipitation, rivers, dams and drainage, but none for tide gauges, predicted astronomical tide or surge height. The forecasting protocol of Chapter 5 describes a 1D river model and a 2D inundation model driven by rainfall; in both, the downstream boundary where a river meets the sea is not described. In practice this means a v1.0 deployment can publish a coastal-flood warning, but the evidence behind it has to come from outside the standard.
When v1.1 adds coupling, it will have to settle at least three questions: how sea-level observations and surge forecasts are represented (a new observation object alongside RiverLevelData is the obvious shape), how the tidal boundary condition is passed into the river and inundation models, and how the joint probability of high river flow and high sea level is expressed in FloodPredictionResult. Until then, the honest way to declare coastal capability is through the interoperability profile described in Chapter 7: mark the relevant requirements partial or excluded with a reason, rather than letting the enum value imply a capability that the protocol does not define.
Urban flood depth changes over short distances: a kerb, an underpass entrance or a basement ramp can decide whether water enters a building. Models built on DEMs coarser than the features that steer water will blur exactly those details. By placing sub-metre lidar inundation out of scope, v1.0 is not saying such models are wrong; it is saying that the standard does not yet define how their outputs are exchanged or validated. The resolution parameter of FloodPredictionRequest is qualitative (coarse, medium, fine) and carries no grid size. A future revision that brings high-resolution inundation into scope would need, at minimum, a way to state the DEM source and grid spacing in the result, because a maxDepth of 0.4 m means different things at 1 m and at 30 m resolution.
Several artefacts are referenced by the v1.0 documents but are not present in the published package: the consolidated specification spec/WIA-ENE-033-v1.0.md, the OpenAPI document api/openapi.yaml, the test vectors under tests/phase-vectors/, and Annex A, which the release notes name as the home of the conformance tiers. Chapters 4 and 7 worked around these gaps; here they appear as roadmap items because they are prerequisites for everything else. Test vectors in particular are the mechanism by which two independent implementations discover that they disagree. Until they exist, conformance claims rest on self-description.
The table below brings the forward-looking items together. The "Published intent" column quotes only what the v1.0 documents say. The last column is this book's recommendation and has no normative status.
| Item | Status in v1.0 | Published intent | Recommendation for adopters |
|---|---|---|---|
| Storm-surge coupling | coastal-flood exists as an event type; no sea-level objects or coupling protocol | Roadmap item for v1.1 (release notes) | Declare coastal capability as partial/excluded in the profile manifest |
| Inundation on DEMs finer than 1 m | Out of scope | No version named | Record DEM source and grid spacing in deployment documentation |
| OpenAPI document | Referenced, not published | Referenced as the home of the operation groups | Generate one from your deployment and include it in the evidence package |
Test vectors (tests/phase-vectors/) | Referenced, not published | Annex G: positive and negative vector per normative requirement | Maintain local vectors; contribute them upstream |
| Annex A (conformance tiers) | Referenced, not published; two vocabularies in use | Not stated | Use the reading given in Chapter 7 and state it explicitly |
| Gauge ingest in the SDK | gaugeIngest group defined; no SDK endpoint | Not stated | Build ingest in the deployment; keep it behind the same auth as other writes |
| SDK retry behaviour | retries configurable but not implemented | SDK is "Reference" tier, versioned independently (Annex F) | Implement retries with backoff in the caller for idempotent reads only |
| Deprecation window | Annex F says at least 90 days of overlap; Annex H says at least 180 days | Not reconciled | Plan for the longer figure until an erratum settles it |
Annex F of each PHASE document also classifies content into three stability tiers: Stable (normative MUST/MUST NOT text, governed by semantic versioning), Provisional (the items of Annex F itself and of Annex D, which may be promoted to normative status without a major version bump), and Reference (test vectors, simulator behaviour and the TypeScript SDK, versioned independently of the documents). This classification is the practical key to reading the roadmap. Dropping the MUST that obliges warningPublish to emit CAP 1.2 would be a breaking Stable change and would require a major version; a fix to the SDK's missing retry loop is a Reference change and can ship at any time.
Chapter 1 introduced four flood types as if they were separate. The most damaging events often are not. A compound flood is one in which two or more drivers coincide so that their combined effect exceeds what either would produce alone. Typical combinations include heavy rainfall on a coastal city while a storm surge holds the sea high, so that rivers and drains cannot discharge; a river already near bank height when an upstream reservoir must increase its release to protect the dam; and intense urban rainfall that overwhelms drainage at the same moment that the receiving river is too high for outfalls or pumps to discharge into it.
┌──────────────────────────┐
Rainfall ─────────▶│ │
(PrecipitationData)│ │
│ Local water level at │
Upstream flow ────▶│ the point of interest │──▶ inundation
(RiverLevelData) │ │ (inundationArea)
│ joint effect ≥ sum of │
Dam release ──────▶│ the separate effects │
(DamStatusData. │ when drivers coincide │
dischargePlan) │ │
│ │
Sea level / surge ▶│ (no v1.0 object; │
(tide + surge) │ v1.1 roadmap) │
└────────────▲─────────────┘
│
Drainage capacity ──────┘ (DrainageData: pumps and outfalls
(limits how fast water stop working when the receiving
can leave the city) water is too high)Three of the drivers in this diagram already have ENE-033 objects. That is a real strength of v1.0: a forecasting node that consumes PrecipitationData, RiverLevelData, DamStatusData and DrainageData through one schema family can reason about their coincidence. What the standard does not yet express is dependence. FloodPredictionResult.contributingFactors lists the drivers side by side, but it has no way to state that the result was computed from their joint behaviour rather than from each one alone. For compound events that distinction is the entire point, because treating dependent drivers as independent tends to underestimate how often they coincide.
Until the standard addresses this, two practices help. First, forecasters should treat dam release plans as forecast inputs, not as after-the-fact observations: dischargePlan is available before the water arrives downstream, and publishing it through the same pipeline as gauge data is one of the most concrete benefits of the river-basin integration pattern in Chapter 6. Second, the scenarios block of FloodPredictionResult (best case, worst case, most likely) is the natural place to show compound combinations explicitly, for example a worst case in which the planned release coincides with the forecast rainfall peak.
PrecipitationData.statistics carries returnPeriod (years), percentile and isExtreme. The classical way to estimate a return period assumes stationarity: the statistics of the past record describe the future. A warming climate undermines that assumption. The physical reason is well established: the amount of water vapour saturated air can hold rises by roughly 7 % per degree Celsius of warming (the Clausius–Clapeyron relation), which gives heavy rainfall more water to work with. Land-use change adds a second non-stationarity: more sealed surfaces turn a larger share of the same rainfall into fast runoff.
The consequence for a data standard is simple to state. A number such as "returnPeriod": 100 is meaningless without knowing which record and which method produced it. For example, suppose an event classed as a 100-year rainfall on a historical record now has an annual exceedance probability of 2 % rather than 1 %; it is then effectively a 50-year event. Applying the formula from Chapter 1 over a 30-year horizon, the chance of at least one such event rises from about 26 % to about 45 %. The field value would still say 100 if nobody updated the analysis.
Version 1.0 has no field for the reference period or the estimation method. Annex E states that additive changes such as new optional fields are non-breaking, so a deployment can add them without breaking consumers. The following is a proposal made by this book, not part of v1.0:
"statistics": {
"returnPeriod": 100,
"percentile": 99.2,
"isExtreme": true,
"x-referencePeriod": { "start": "1981-01-01", "end": "2020-12-31" },
"x-method": "annual-maxima, GEV fit",
"x-stationarity": "stationary-assumed"
}The x- prefix marks the fields as local extensions so that they cannot collide with names a future version might standardise. Consumers that do not understand them will ignore them, and auditors can see at a glance that a 100-year label rests on a 40-year record analysed under a stationary assumption. The values shown are illustrative.
PHASE-3 describes an AI model built from LSTM layers for time series, CNN layers for spatial patterns and an attention mechanism, and it places that model beside a hydrological (Saint-Venant and shallow-water) model and a statistical model inside an EnsemblePrediction. This reflects a real direction in the field: data-driven models, especially recurrent networks trained on many basins, have proven competitive for rainfall–runoff prediction, while physically based models remain essential where data are sparse, where conditions fall outside the training record, or where the output must be a spatial depth map that obeys conservation of mass.
The research frontier is less about choosing one over the other and more about combining them: using physics-based simulations to generate training data for rare events, constraining learned models with mass balance, or using machine learning to correct the systematic errors of a physical model. ENE-033's ensemble structure already accommodates this, because members are exchanged as ordinary FloodPredictionResult objects regardless of how they were produced. What it does not yet carry is provenance: there is no field recording which model version, which training period or which input data produced a member. As learned models are retrained more often than physical models are recalibrated, that gap will grow in importance, since a change in skill after a retrain is invisible unless the version is recorded.
The README assigns short-range forecasts (1–6 h) to real-time rainfall radar. For flash floods and urban flooding, the most valuable lead time is often measured in minutes to a few hours, and the dominant technique in that range is nowcasting: extrapolating the motion and evolution of the observed radar echo. Nowcasting skill decays quickly with lead time, because it cannot foresee new storm cells forming; numerical weather prediction takes over at longer ranges, and blending the two is standard practice in operational services.
In v1.0, PrecipitationData.radar is a reference to an image (imageUrl, coverage in km, lastUpdate). That is sufficient for display but not for computation: a model cannot ingest a picture URL as a rainfall field. A natural evolution would be a gridded precipitation object, or a reference to a gridded dataset in a recognised format, with explicit grid spacing, time step and units. Where a weather service already publishes gridded nowcasts, a deployment should consume that product directly and use ENE-033 for the derived point and basin series.
ENE-033 is probabilistic at its core: FloodPredictionResult carries both probability and confidence, and ensembles report mean, median and uncertainty. Public alerts, however, are categorical: a CAP message has one severity, one urgency, one certainty. The translation from a probability distribution to a single category is where most communication failures happen. Studies of how people respond to warnings have long emphasised that action depends heavily on whether the message says clearly what to do and whether it concerns the recipient's own location; a bare probability rarely carries that information.
Two practical consequences follow. The instructions.actions array is at least as important as the risk level, and should be written as concrete actions ("move vehicles out of underground car parks") rather than descriptions of the hazard. And the certainty value sent to CAP should follow from a documented rule tied to the ensemble, not from a forecaster's mood on the day. Chapter 3 described the mapping of FloodAlert fields to CAP; the forward-looking point is that the mapping rule itself belongs in the deployment's published documentation, so that recipients can interpret a "likely" consistently across events.
PHASE-2 §12.1 lists a smart-city platform among the external systems, with three capabilities: trafficControl, infrastructureMonitoring and citizenServices. In v1.0 these are booleans. They say that an integration exists, not what it exchanges. The direction many cities are moving in is an urban digital twin: a continuously updated model of the city's buildings, roads, drainage and sensors, against which forecasts can be evaluated asset by asset.
For flood response, the most valuable link is between inundation forecasts and routing. EvacuationRoute.hazards.floodedSegments already carries segments with a start, an end and a water depth in metres, and RouteStatus distinguishes clear, caution and blocked. If those segments are refreshed from the latest inundationArea and from road-level sensors, the evacuation API becomes a live routing service rather than a static list. The following sketch shows the idea. The depth limits are placeholders, not safety guidance: the thresholds at which a road must be closed depend on vehicle type, water velocity and local road-authority rules, and must be set by the responsible authority.
import { FloodedSegment, RouteStatus } from './types';
// Placeholder limits in metres. Replace with values set by the road authority.
const CAUTION_DEPTH_M = 0.05;
const BLOCK_DEPTH_M = 0.15;
function segmentStatus(seg: FloodedSegment): RouteStatus {
if (seg.depth >= BLOCK_DEPTH_M) return RouteStatus.BLOCKED;
if (seg.depth >= CAUTION_DEPTH_M) return RouteStatus.CAUTION;
return RouteStatus.CLEAR;
}
// A route is only as passable as its worst segment.
function routeStatus(segments: FloodedSegment[]): RouteStatus {
const order = [RouteStatus.CLEAR, RouteStatus.CAUTION, RouteStatus.BLOCKED];
return segments
.map(segmentStatus)
.reduce((worst, s) => (order.indexOf(s) > order.indexOf(worst) ? s : worst),
RouteStatus.CLEAR);
}Note the explicit ordering array. It follows the same advice given in Chapter 5 for RiskLevel: never rely on the lexical order of string enum values to rank severity.
Three cautions apply to digital-twin integration. First, a twin is only as current as its slowest feed; a routing service that shows a road as clear because the depth sensor went offline is worse than one that shows it as unknown, and v1.0's RouteStatus has no unknown value, so a deployment should treat stale data as caution at best. Second, the twin multiplies the number of systems that can write to safety-relevant state; the RBAC discipline of Chapter 6 must extend to it. Third, open city-model standards exist for exchanging building and terrain geometry (the OGC CityGML standard is the best known), and a flood deployment should consume them rather than invent its own geometry format.
PHASE-4 cites the Sendai Framework for Disaster Risk Reduction 2015–2030, adopted by UN member states in 2015. Of its seven global targets, target G calls for substantially increasing the availability of and access to multi-hazard early warning systems and disaster risk information by 2030. In 2022 the UN Secretary-General launched the Early Warnings for All initiative, led by WMO with UNDRR, ITU and IFRC each leading one of its pillars, with the aim that everyone on Earth be protected by early warning systems by the end of 2027. It is organised around four pillars that match the chain described in Chapter 1: risk knowledge, observation and forecasting, warning dissemination and communication, and preparedness to respond.
These frameworks are policy context, not requirements of ENE-033, and conforming to ENE-033 does not in itself constitute Sendai reporting. They are relevant because they define success in terms of people reached, not models run. That shifts attention to the last part of the chain, where the standard has specific features and specific gaps.
FloodAlert.instructions has exactly two text fields, ko and en. That covers Korean and English speakers but not migrant workers, tourists or residents whose first language is something else. CAP 1.2 already solves this at the message level: one <alert> may contain several <info> blocks, each with its own <language> code. A publisher can therefore keep the two v1.0 fields for its own schema and emit additional languages only in the CAP output, as in this illustrative fragment (identifiers, times and coordinates are examples):
<alert xmlns="urn:oasis:names:tc:emergency:cap:1.2">
<identifier>example-basin-2026-0001</identifier>
<sender>warnings@basin.example.org</sender>
<sent>2026-07-15T14:00:00+09:00</sent>
<status>Actual</status>
<msgType>Alert</msgType>
<scope>Public</scope>
<info>
<language>ko-KR</language>
<category>Met</category>
<event>하천 홍수</event>
<urgency>Expected</urgency>
<severity>Severe</severity>
<certainty>Likely</certainty>
<instruction>하천변 저지대 주민은 지정 대피소로 이동하십시오.</instruction>
<area><areaDesc>예시 하천 하류 저지대</areaDesc></area>
</info>
<info>
<language>en-US</language>
<category>Met</category>
<event>River flood</event>
<urgency>Expected</urgency>
<severity>Severe</severity>
<certainty>Likely</certainty>
<instruction>Residents of low-lying riverside areas: go to your designated shelter.</instruction>
<area><areaDesc>Low-lying area, lower reach of example river</areaDesc></area>
</info>
<info>
<language>vi-VN</language>
<!-- same structure; translated text prepared in advance -->
</info>
</alert>The practical lesson is that translation cannot happen during the emergency. Instruction templates in each supported language should be written, reviewed by native speakers and stored in advance, with only place names and times filled in at issue time.
AlertDistribution.recipients includes a vulnerable group alongside high-risk residents, first responders, public officials and the general public, and the channel list includes sirens, radio and television as well as SMS and push. This is the right structure: people who cannot hear a siren, cannot read small text on a phone, or cannot evacuate without help need different channels and earlier notice. EvacuationShelter.accessibility likewise records whether a shelter can receive them. Two improvements are worth pursuing. Alert pages and apps should meet recognised web accessibility guidance such as W3C WCAG 2.x; and the lead time used to trigger notices for the vulnerable group should be longer than for the general public, since their evacuation takes longer. Neither is a v1.0 requirement, and the data needed to target a vulnerable group is personal data, so the minimisation principles of Chapter 6 apply in full.
PHASE-3's AlertCriteria has two halves. The automatic half defines conditions (risk level at least LEVEL-2, probability at least 60 %, a minimum lead time and a minimum affected population) under which an alert may be raised without waiting for a person. The manualReview half names conditions under which a person must look: high uncertainty, critical infrastructure and historical significance. The numerical defaults are reference-implementation values, not validated thresholds, as Chapter 5 explained.
The README's long-term vision includes "AI autonomous response: full automation". This book does not endorse that goal, for three reasons. First, legal authority: in most countries, including Korea, the power to issue official flood forecasts and to order evacuation is assigned by law to specific public bodies, and a software system cannot hold that authority. The official Korean forecast terms (홍수주의보 and 홍수경보, issued by the flood control offices) are distinct from ENE-033's LEVEL scale, as Chapter 1 stressed. Second, accountability: when an alert is wrong, someone must be able to explain why it was issued and on what evidence; that requires a human decision point for at least the high-consequence classes of alert. Third, the rare-event problem described in Chapter 5: models are weakest exactly where floods are most extreme, because such events are scarce in the training record.
A defensible design treats automation as a way to buy time, not to remove judgement. Automatic issuance is reserved for narrowly defined, pre-authorised cases, for example raising LEVEL-1 or LEVEL-2 advisory notices to officials when an observed rate of rise crosses a documented threshold, while anything that triggers evacuation passes through manualReview. The system's role is to present the evidence, draft the CAP message and start the clock, so that the human decision takes minutes rather than an hour.
Version 1.0's FloodAlert records the issuer but not the basis for the decision. For after-action review and for any liability question, the following should be retrievable for every alert: the prediction IDs that informed it, the model versions in the ensemble, whether it was issued automatically or after review, and who approved it. None of these need to be in the public CAP message. They belong in the audit log described in Chapter 6, linked by alertId. If a future version adds them to the schema, they should go in an internal envelope, not in the public payload.
Every warning system trades false alarms against missed events. Lower the threshold and more floods are caught, but more alerts turn out to be unnecessary; raise it and the reverse happens. Repeated unnecessary alerts can erode public response, a phenomenon often called warning fatigue, although some studies suggest the effect is weaker than commonly assumed, and that explaining why an alert did not materialise helps preserve trust. The spec's design targets (a false-alarm rate of at most 15 % alongside high recall) state an intent, not a proof; Chapter 5 showed why these metrics must be defined on a contingency table before they mean anything. The forward-looking recommendation is to publish verification statistics per season, including missed events, and to review the thresholds in AlertCriteria against them. A threshold that has never been re-examined against outcomes is a guess, however precise it looks.
| Decision class | Suggested mode | Rationale |
|---|---|---|
| Internal advisory to duty forecaster | Fully automatic | No public consequence; speed matters most |
| LEVEL-1/LEVEL-2 notice to officials and responders | Automatic under pre-authorised rules, human notified | Buys preparation time; reversible |
| Public alert at LEVEL-3 or above | Drafted automatically, issued after human approval | Legal authority and accountability |
| Evacuation order | Human decision by the legally competent authority | Highest consequence; the system supplies evidence only |
| Cancellation or downgrade | Human decision, with the same review as issuance | A premature all-clear can be as harmful as a late warning |
The table is this book's suggestion, not a requirement of ENE-033. It is written to be consistent with the two halves of AlertCriteria and with the principle that the system provides evidence while legally responsible people decide.
The README invites four kinds of contribution: technical feedback through GitHub issues, case studies of implementation experience, translations, and proposals to improve the data format or API. Annex F of each PHASE document adds that roadmap comments are accepted through the issues tracker of the WIA-Official organisation on GitHub, and advises implementers to subscribe to release notifications to follow promotions between the Stable, Provisional and Reference tiers. The public repository linked in this chapter's references is the place to start.
The most useful contributions are the ones that close the gaps listed in Section 8.1: test vectors derived from real deployments (with personal data removed), corrections to inconsistencies such as the two deprecation windows or the two conformance vocabularies, and worked mappings between ENE-033 objects and the formats your agency already uses. A contribution that reports a negative result, a place where the standard could not express what your operations needed, is as valuable as one that adds a feature.
The README lists five related WIA standards: WIA-ENE-001 (climate change management), WIA-ENE-012 (water quality monitoring), WIA-ENE-019 (air quality monitoring), WIA-ENE-029 (ecosystem monitoring) and WIA-CITY (smart-city integration). Of these, WIA-CITY is the closest companion for the digital-twin work of Section 8.4, and WIA-ENE-001 for the climate questions of Section 8.2. ENE-033 also depends on external standards that are not WIA documents, notably OGC WaterML 2.0 for observations, OASIS CAP 1.2 for alerts and the WMO HOMS components for hydrological practice. ENE-033 is a WIA standard that references these international standards; it is not itself an ISO, IEC or WMO standard, and it should not be described as one.
For an organisation deciding whether to adopt ENE-033, the following sequence turns the book into action. It is ordered by dependency, not by calendar.
| Step | What to do | Chapter |
|---|---|---|
| 1 | Inventory gauges, rain gauges, dams and drainage assets; record datums, units and clock sources | 2 |
| 2 | Write the explicit mapping from threshold levels and LEVEL-0..4 to your official forecast and crisis terms | 1, 3 |
| 3 | Choose the integration pattern and topology; decide who may call /alert/create | 6 |
| 4 | Stand up ingest and the prediction API; validate sample objects against the schemas | 2, 4 |
| 5 | Run at least two ensemble members and start keeping verification statistics from day one | 5 |
| 6 | Emit CAP 1.2 alongside the native alert; prepare multilingual instruction templates | 3, 8 |
| 7 | Publish a profile manifest that honestly marks partial and excluded requirements | 7 |
| 8 | Rehearse end to end with a drill, then review thresholds against the results | 6, 8 |
x- fields can record them without breaking consumers.floodedSegments into live routing, provided stale data is never shown as clear.<info> blocks and the vulnerable recipient group are the tools for that.Floods will keep changing faster than standards can be revised. The value of a shared standard lies less in any single version than in giving hydrologists, forecasters, emergency managers and software vendors a common vocabulary for finding and fixing its gaps together.