Two gaps in the impact model: forecasts, and exposure

[emmanuelmathot]

Raised from #89, where the GDACS tropical cyclone timeline mapping ran into both. Proposed as a Montandon TWG agenda item.

The GDACS mapping for impacts[].resource.timeline is now written down. Two questions came up while writing it that the GDACS document cannot answer on its own. Both belong to the Monty model. This discussion is to settle them.

The evidence

GDACS publishes a cyclone advisory timeline. Each entry is one point on the storm track. The entry carries a population count for each wind band. Here is the timeline of cyclone NOUL-26, episode 13 (eventid=1001294), read live on 2026-08-03:

advisory	actual	advisory_datetime	wind_speed	pop39	pop74
9	True	25 Jul 2026 06:00	38.58	75,490,475	614,941
11	True	25 Jul 2026 18:00	43.724	103,014,755	11,167,854
13	True	26 Jul 2026 00:00	38.58	80,042,232	10,640,921
13	False	26 Jul 2026 12:00	23.148	14,518,892	0
13	False	27 Jul 2026 00:00	15.432	0	0

actual: True marks an observed track position. actual: False marks a forecast position. Every population figure in the table, on both kinds of row, comes from the same GDACS population model applied to a wind footprint.

Question 1 — should Monty mark an estimate as a forecast?

Monty has no field for this. The closest field is monty:impact_detail.estimate_type, with the values primary, secondary and modelled. That field describes where a figure comes from. It does not describe whether the figure is about the future.

The two axes are independent:

	About the past	About the future
Observed / reported	EM-DAT death toll	—
Modelled	USGS PAGER, post-event	GDACS cyclone forecast track

A GDACS forecast and a USGS post-event PAGER run both map to modelled today. A consumer cannot tell them apart, except by comparing the item datetime to the time it read the catalogue — which is not a stable test, and fails entirely on a historical query.

This is not only a GDACS problem. PDC publishes forecast products. The Monty model text already says an event "has occurred or is forecasted to occur", and docs/model/README.md describes start_datetime and end_datetime as "when the impact estimate started or is forecasted to start". So the model already assumes forecasts exist. It just gives no way to query for them.

Two implementations exist in the wild, both undeclared:

• pystac-monty sets a bare item property forecasted: true|false for GDACS TC (gdacs.py:542) and for USGS (usgs.py:717).
• Neither is in the extension schema. Both pass validation, because the schema's patternProperties allows any key without the monty: prefix. So they are invisible to the extension, unnamespaced, and undiscoverable.

The instinct is right. The field needs specifying.

Options

1a. Add monty:impact_detail.observation_type. Values observed and forecast. Small change. It sits beside estimate_type, where a consumer already looks. It does not carry the issue time or the lead time, so it cannot support forecast verification.

1b. Add an item-level monty:forecast object.

"monty:forecast": {
  "issue_time": "2026-07-26T00:00:00Z",
  "valid_time": "2026-07-27T00:00:00Z",
  "lead_time_hours": 24,
  "reference": "JTWC advisory 13"
}

Presence marks the item as a forecast. Absence means observed. It carries enough to support forecast verification later. It applies to hazard items and impact items alike, which matters because a cyclone track point is arguably both. Larger change.

1c. Add forecast to the estimate_type enum. Cheapest. Rejected in the GDACS write-up, and stated here for completeness: it conflates the two axes, and it silently loses the provenance of a forecast figure, which is always modelled.

Recommendation: 1b. The lead time is the field that makes forecast data usable, and 1a cannot be extended to carry it without a second change later.

Question 2 — is exposure an impact?

pop39 counts the people inside the 39 kt wind field. It does not count the people the cyclone harmed. UNDRR keeps these apart: exposure is the presence of people or assets in hazard-prone areas; impact is the effect of the hazard on them.

Monty has no exposure class. The GDACS mapping therefore files exposure under monty:impact_detail with type: potentially_affected. That is a compromise, and it has costs:

• potentially_affected is now doing two jobs. For GDACS it means "inside the footprint". For other sources it can mean an early, uncertain affected-persons estimate.
• A consumer summing affected persons must know to exclude it, per source.
• The figures are large. 103 million people in the 39 kt field is not a claim that 103 million people were affected. Presented in an impact collection, it reads like one.
• Exposure figures are not only about people. The GDACS buffer39 response also lists exposed airports, ports, cities, hydro installations and nuclear plants, with model provenance. Monty currently maps none of it.

Options

2a. Keep exposure inside Impact. Status quo. Document the convention per source, as the GDACS doc now does. Zero schema change. The ambiguity stays, and it grows with each source that publishes exposure.

2b. Add an exposure value to monty:impact_detail.type, or a flag on the detail object. Cheap and explicit. Exposure items stay queryable in the same collection as impacts, which keeps the "what do we know about this event" query simple.

2c. Make Exposure a Monty class of its own, beside Event, Hazard, Impact and Response, with *-exposure collections. Cleanest conceptually. It matches how the DRR field draws the line, and it gives the non-population exposure (infrastructure) somewhere to live. Largest change: new role, new collections, ETL and consumer migration.

Recommendation: 2b now, 2c on the roadmap. 2b removes the ambiguity for a small cost and does not block 2c. Deciding 2c properly needs a survey of which sources publish exposure, which is more work than this issue can carry.

What is blocked

Nothing urgent. The GDACS mapping ships with the rules as documented, and the compromise recorded. Both questions become migrations when settled, not rewrites.

Asks of the TWG

1. Is the observed/forecast distinction a field Monty should carry? If yes, 1a or 1b?
2. Is exposure distinct enough from impact to earn its own type value, or its own class?
3. Who else publishes forecast or exposure data that these choices must fit? PDC and GDACS are known. Others?

References

• GDACS source doc, Impact Item section — the mapping and the two decisions it had to take
• #89 — where this started
• UNDRR terminology: exposure
• GDACS tropical cyclone model

[emmanuelmathot]

cc @arnauroviramuntada @ranjan-stha @wrynearson

[wrynearson]

Thanks for opening this discussion @emmanuelmathot

Question 1

Regarding the existing estimate_type property – could you link to definitions of the three possible values (primary / secondary / modelled)? I searched this repo and didn't find any definitions of what these mean, only the three possible values and a few source-specific mappings (e.g., IDMC).

I agree that option 1b is the best from a user perspective. I think we should implement it, and (optionally) extend it depending on data upstream. Example ideas below:

"monty:forecast": {
  "issue_time": "2026-07-26T00:00:00Z",
  "valid_time": "2026-07-27T00:00:00Z",
  "lead_time_hours": 24,
  "reference": "JTWC advisory 13"
  "confidence": "0.7" # this could be valuable if provided upstream
  "resolution": "3" # likely most applicable to weather forecasts
  "resolution_unit": "km"
}

Question 2

potentially_affected is now doing two jobs.

I think this is a pretty large issue that we should address. The number of people exposed to a hazard will often be wildly different to the number of people impacted by a hazard. Conflating the two in the same item property is not only incorrect, but I'd argue a credibility issue.

I largely agree that option 2b is correct to implement now and 2c would be worth exploring, especially in the context of baseline hazard exposure and anticipatory action themes. Having data that covers baseline exposure, forecasted exposure (to a specific upcoming hazard), initial impact data, and response data is quite a compelling data set / product.

[p-phung]

Without knowing how the data will be used downstream or even the larger data model around this makes it difficult for me to give comment how it should structure. I share some thoughts still at the surface level:

Question 1:

• Yes it should, based on the fact that impact estimate and report impact are always different numbers and even have distinct sets of keys/metadata.
• Having a clear keys between forecast estimate impact and reported one would be more handy for to query and further analyses.
• With these arguments, the option 1b seems to be the most logical. I can also imagine that it would be also less invasive to append a new object (1b) than inject to a conflating object (1c)

Question 2:

• Yes it should be separated. As you already mentioned, exposure and impact data have somewhat separate use cases.
  • From DRR perspective, exposure is more of physical disaster path and could be useful for scenarios plannings, while impact is more about actual damages, losses because of the physical disaster path.
  • From DREF, EAP sides, exposure would need different preparedness actions compared to real impact response
• Having a clear distinction that follow widely known UNDRR definitions would makes Monty more interoperable
• I would go for 2c as it creates quite clean structure.

[wrynearson]

Thanks for this context @p-phung – it's very helpful

[emmanuelmathot]

Picking this up after @wrynearson's and @p-phung's replies. They converged on the same pair of answers (1b for Q1, and 2c for Q2, with @wrynearson taking 2b as a step toward it), so rather than re-argue those, I want to add the piece that I think makes both concrete: Q1 and Q2 are the same question asked on two different axes, and an existing standard already draws both axes for us.

The two axes

Reading Q1 and Q2 side by side:

• Q1 (forecast vs observed) asks how certain is this figure, and when does it apply?
• Q2 (exposure vs impact) asks what kind of thing is this figure about?

These are independent. A figure can be observed-exposure, forecast-exposure, observed-loss or forecast-loss. The table in the original post already shows this for Q1; the same table works for exposure. Today Monty collapses both axes into monty:impact_detail, which is why potentially_affected keeps absorbing new meanings and why forecasted had to be invented outside the schema.

There is an existing classification for the second axis

The Risk Data Library Standard (RDLS), curated by GFDRR, defines four risk-data components:

Hazard · Exposure · Vulnerability · Loss

_{RDLS metadata structure. Source: docs.riskdatalibrary.org}

The shape of that diagram is the part worth noticing for us. RDLS puts the fields common to everything at the dataset level, then groups the fields that are specific to a type of risk data under one object per component: Hazard, Exposure, Vulnerability, Loss. That is the same move Monty already makes with monty:hazard_detail, monty:impact_detail and monty:response_detail. We are not being asked to adopt a foreign structure, we are already using it, with two of the objects missing (more on that below).

It is not one organisation's model. GEM led the exposure component, UCL EPICentre the vulnerability component, and BGS the hazard component. The same quadrant recurs in INSPIRE Natural Risk Zones (NaturalHazard / ExposedElement / VulnerabilityAssessment / RiskZone) and in the OASIS Loss Modelling Framework. Underneath all of them is the UNDRR risk framing already cited in this thread, R = f(H, E, V).

That convergence is the argument. @p-phung asked for a clear distinction that follows widely known UNDRR definitions, because it "makes Monty more interoperable". RDLS is that distinction: already written down, already implemented by the modelling community, and already the vocabulary GEM and GFDRR publish data in.

Monty already sits on this quadrant, with two legs present and two missing:

RDLS component	Monty today
Hazard	✅ Hazard class
Loss	✅ Impact class
Exposure	⚠️ vocabulary present, class absent
Vulnerability	❌ absent entirely

Monty already contains the exposure vocabulary

This is the part I forgot (this was done 2 years ago :-). docs/model/taxonomy.md has a section titled "Exposure Category", nested under ## Impact:

people, crops, women, men, children_0_4 … elderly, wheelchair_users, roads, railways, buildings, hospitals, schools, cattle, households

That is an exposed-asset and population taxonomy, close in shape to what GEM produced for RDLS. monty:impact_detail.category is documented as "exposure category" and the IFRC-DREF source doc links to it under that name. So an Exposure class would not need a new vocabulary invented for it. It would reclaim the one already written, currently filed under the wrong parent.

The pressure is already visible in four places

@wrynearson put the cost of leaving this alone more sharply than the original post did: conflating exposure and impact in one property is "not only incorrect, but I'd argue a credibility issue". Worth noting how much surface that already covers: exposure is not a hypothetical future need, it is already being worked around in four places.

1. GDACS: this thread's pop39/pop74, with an explicit "Decision: exposure is not impact" section recording the compromise.
2. CEMS: the source doc specifies "one Impact item for each exposure class" for GRA products.
3. USGS PAGER: json/exposures.json (population by MMI level) is attached only as an asset, unmapped, because there is nowhere for it to go.
4. Response taxonomy: eo-pop "Population Exposure" already exists as a response type.

Four sources, four different workarounds, one missing class.

Vulnerability answers "what else have we not anticipated?"

The reason to reach for the whole quadrant rather than only adding Exposure: Vulnerability is the component nobody has raised yet, and it will arrive. Fragility curves, building-stock vulnerability indices, INFORM-style susceptibility indicators, IFRC's own vulnerability assessments are all Vulnerability data in the RDLS sense, and none of them fit Hazard, Impact or Response. Adopting the quadrant means that when it turns up, the class already exists and the boundary is already drawn by someone else.

What this means for Q1, and why it is not the same fix

RDLS deliberately keeps uncertainty out of the component axis. It handles it with separate, cross-cutting fields applied within a component:

• analysis_type: probabilistic or deterministic
• frequency_distribution, occurrence_range: the shape and range of modelled occurrence
• data_uncertainty: uncertainty attached to a footprint

So the answer to Q1 is not solved by adding an Exposure class, and vice versa. Both need answering. The useful part is that RDLS shows they should be answered separately, as an observed/forecast/probabilistic qualifier that applies to any component, rather than three more values crammed into impact_detail.

That reframes option 1b (monty:forecast object): it is the right instinct, and it becomes more clearly right if it is understood as the uncertainty axis, applicable to Hazard, Exposure and Impact alike, not as an Impact-specific patch. @wrynearson's suggested confidence and resolution additions fit that reading, as does analysis_type: probabilistic for cases like the USGS PAGER alert histogram (see below).

On the estimate_type question

@wrynearson asked for the definitions of primary / secondary / modelled and could not find them in the repo. I could not either: the three values appear in the schema enum, in the field table, and in per-source mappings, but nowhere with a definition attached.

That gap is worth reading as evidence rather than an oversight. estimate_type is the only field in monty:impact_detail that says anything about how a figure came to be, so it has quietly been asked to carry two different jobs: provenance (who produced this, from what) and confidence (how much do we trust it). Those pull in opposite directions, which is exactly why the values resist definition. RDLS keeps them apart, with provenance in the dataset-level metadata and analysis_type / frequency_distribution / data_uncertainty describing the analysis. If we settle the uncertainty axis properly, estimate_type gets narrow enough to define in one line each.

A worked case that shows the two axes are distinct

USGS PAGER publishes json/alerts.json: a probability histogram over fatalities and economic loss (seven bins each, probabilities summing to 1.0). This surfaced via pystac-monty#200 and is tracked in #125.

It is worth being precise about what it is:

• It is Loss on the component axis: a distribution over deaths and cost, not exposure. An Exposure class would not absorb it.
• It is probabilistic on the uncertainty axis.
• The current ETL maps it to type: potentially_affected, which is neither. That is a third independent piece of evidence that potentially_affected has become the place where anything that does not fit goes.

Two proposals came out of it: #128 (adding value_min/value_max/probability to monty:impact_detail) and #129 (one impact item per bin). Both are on hold pending this discussion, because they are exactly the kind of per-source patch on the uncertainty axis that this thread is trying to stop. If the quadrant framing is adopted, they should be reworked to match it rather than merged as they stand.

The unconditional corrections from the same investigation were split into #130 and are independent of any of this. One is worth flagging on its own: PAGER's economic alert bins are denominated in millions of USD despite alerts.json labelling them "units": "USD", verified against PAGER's published alert thresholds (yellow >= $1M, orange >= $100M, red >= $1B). The ETL copies the label through, so those values are currently published 10^6 too small.

Proposal

On Q2, adopt the RDLS component framing rather than a local invention. In the terms of the original post this is closest to 2c, but with the boundaries taken from an existing standard instead of drawn fresh. That is @p-phung's preference ("2c as it creates quite clean structure"), and it is also the cheaper version of 2c: most of the design work is already done and published.

It also answers @p-phung's operational point that exposure and impact drive different DREF and EAP actions. Once they are separate classes, "who is in the footprint" and "who was harmed" stop being the same query with a type filter, which is what an anticipatory-action trigger actually needs.

The concern about keeping the model understandable is, I think, met rather than harmed. Monty becomes:

1 correlation spine (Event) + the 4 standard risk components (Hazard, Exposure, Vulnerability, Loss/Impact) + 1 action class (Response)

Six classes, but four of them stop being Monty-specific definitions and inherit boundaries the DRR community already knows and can look up. That is less to explain, not more. Event and Response have no RDLS equivalent, which is fine: they are Monty's own contribution, and the operational/humanitarian side is precisely where Monty adds something RDLS does not have.

What the new classes would carry

The extension already has one detail object per class, so new classes do not need a new mechanism, only the matching objects:

Class	Detail object	Status
Hazard	monty:hazard_detail	exists
Exposure	monty:exposure_detail	new
Vulnerability	monty:vulnerability_detail	reserved, define on demand
Impact (Loss)	monty:impact_detail	exists, narrows
Response	monty:response_detail	exists

(Singular _detail, to match the three that already exist.)

monty:exposure_detail is mostly specified already, just in the wrong place. RDLS builds its exposure component on category (a closed codelist), taxonomy (the scheme naming individual assets, for example GEM's), and metrics[] carrying a dimension and quantity_kind. Monty's existing "Exposure Category" table is that first field, verbatim. A sketch, using this thread's GDACS figure:

"monty:exposure_detail": {
  "category": "people",
  "value": 103014755,
  "unit": "people",
  "estimate_type": "modelled"
}

Two things need settling that impact_detail never had to answer, and both argue for a separate object rather than a flag:

1. Exposure is always exposure to something. A population count is meaningless without the footprint that defines it, so an Exposure item needs a related link to the Hazard item carrying the threshold (the 39 kt band, the MMI level). That relationship has no equivalent on an Impact item.
2. The threshold itself has to be expressed. pop39 and pop74 are the same category at different hazard intensities. Today they are told apart only by prose.

The payoff is that potentially_affected can then be retired from impact_detail, or narrowed to the one meaning it was coined for. Every current use of it that actually means "inside the footprint" moves to monty:exposure_detail, and the field stops being the place where anything unclassifiable ends up.

monty:vulnerability_detail is worth reserving by name now and defining when a source arrives. RDLS says its vulnerability component "uses attributes consistent with the hazard, exposure and loss components" but the public schema reference does not enumerate it in the detail the other three get, so there is no point copying a shape we would have to redo.

On Q1, take 1b, framed as the uncertainty axis, rather than an impact-local field, so the same qualifier can sit on Exposure and Hazard items too. Note this is what the detail-object split buys: whatever monty:forecast ends up looking like, it applies to Exposure and Hazard items exactly as it does to Impact, instead of being defined once inside impact_detail and then needing a second copy per class.

Sequencing that avoids a migration cliff:

1. Agree the framing (this thread / TWG).
2. Add exposure as a role, *-exposure collections, and monty:exposure_detail. Move the "Exposure Category" table out from under ## Impact in the taxonomy, where it already belongs. Existing exposure-as-impact items keep working; sources migrate one at a time.
3. Settle the uncertainty axis (Q1 + #127) as one decision covering forecast and probabilistic data, defined once so it applies to every detail object.
4. Once the four sources above have migrated, narrow or retire potentially_affected in monty:impact_detail. This is the step that actually closes @wrynearson's credibility concern, and it is only safe after step 2.
5. Reserve monty:vulnerability_detail by name. No implementation needed until a source turns up, but naming it now stops the next unanticipated data type being pushed into Impact.

Caveats

• RDLS is a dataset-level metadata standard; Monty is item-level STAC for events. This is an alignment of classes and vocabulary, not wholesale adoption of the RDLS schema. The component boundaries transfer; the field-level structure mostly does not.
• Making Exposure a class is genuinely the larger change. But the counterfactual is not "no change". It is continuing to add per-source workarounds, of which there are already four.

References

• Risk Data Library Standard: what it is, schema reference, GFDRR/rdl-standard
• UNDRR terminology: exposure
• USGS PAGER Scientific Background: the alert thresholds behind the unit finding
• #125, #127, #128, #129, #130

[arunissun]

Thanks, I agree that potentially_affected has become too ambiguous and should no longer be used as a catch-all term. It currently risks mixing people inside a hazard area, early estimates of affected people, and uncertain loss data.

For Question 1, I support option 1b. A separate monty:forecast object seems feasible and clearer than adding “forecast” to estimate_type, because “modelled” and “forecast” mean different things. We should keep the first version small and confirm which sources can provide issue time, valid time and lead time rather than inferring them.

For Question 2, I see a separate Exposure class and collection as the cleaner long-term model. However, I think we should first inventory the current source fields and the queries consumers need. GDACS is clearly exposure, but other sources need separate semantic review.
Could option 2b be an explicit interim step: add exposure as a clear value, keep existing records compatible for now, and document that it must not be counted as an impact? We could pilot this with GDACS, evaluate the queries and migration needs, then decide whether to move to separate Exposure collections.

I also suggest treating USGS PAGER alerts separately: they are probabilistic loss data, not exposure, so they should not be mapped to potentially_affected or moved into an Exposure class.

[emmanuelmathot]

Core partners meeting discussion on 2026-09-09

• @arunissun to own the discussion and to enrich it with partners' input
• Identify the sources falling into those new classes
• separate collections