Every figure has a source, a version and a second reader.

ecosphere is built on public, peer-reviewed or institutionally published datasets that a methodologist can look up independently. We add processing, aggregation to African places, review and delivery; we do not replace the science underneath.

Annual or seasonal averages hide the days that cause losses. We compute each indicator from daily reanalysis fields first, and only then aggregate it to a year and to a place.

Heatwaves and heat percentiles

Counts of hot days and runs of consecutive hot days, judged against local conditions in the 1991–2020 baseline, so “hot” means hot for that place rather than a single continental threshold.

Extreme rain

Days of unusually heavy rainfall for the place, and the annual maximum daily rainfall used for return periods.

Drought (SPI)

The Standardised Precipitation Index: rainfall accumulated over a window (for example 3, 6 or 12 months) is fitted to a probability distribution over the baseline and expressed in standard deviations, so −1.5 means equally unusual in the Sahel and the Highveld.

Heat stress and comfort

Wet-bulb globe temperature (WBGT) for people working outdoors, the temperature–humidity index (THI) for livestock, and humidex for comfort, each derived from daily temperature and humidity.

ENSO phase

The El Niño–Southern Oscillation phase for each year, so drought and rain can be read against the phase that tends to drive them in a region.

Gridded indicators are then summarised for each country, admin-1 region and municipality. The place, the aggregation and the baseline travel with the figure.

A return period is a way of stating an annual probability: a 1-in-100 year event has a 1% chance of being equalled or exceeded in any given year. It does not mean the event happens once a century.

For rainfall, we fit an extreme-value distribution to the annual maxima at each location and read intensities off it at standard return periods. A hazard curve shows the whole relationship, intensity against annual exceedance probability, for a single site, so an underwriter can read 1-in-50 as easily as 1-in-500. Seismic hazard is expressed as peak ground acceleration at 1-in-475 years (a 10% chance of exceedance in 50 years), the convention used in building design.

Disaggregation breaks a site’s hazard into the events or sources that contribute most to it, so you can see whether a flood depth is driven by local rainfall, an upstream catchment or a dam release.

Surface models such as Copernicus DSM record the tops of buildings and trees. Water does not flow over rooftops, so flood depth is modelled on a digital terrain model (DTM) of the bare earth. Where several are available we use the best in a fixed order: LiDAR survey, then our own DTM pipeline, then FABDEM, then Copernicus DSM as the last resort. The terrain source is recorded on every result.

2D flood modelling routes water across that terrain cell by cell, rather than assuming a level pool, so depth responds to channels, embankments and low ground. Results include flood depth at 1-in-100 years and the surge downstream of a dam release. When a better DTM is published for an area, the terrain flood and landslide runs for that area start again, and the new results carry the new terrain version.

A physical shock is defined relative to what is normal for a place. Each of the seven shock types (heatwave like a record year, drought, extreme rain with a 1-in-100 flood, fire season, seismic, landslide and heat discomfort) is expressed as a shock index: how far the shocked year sits from the 1991–2020 baseline distribution for that place. This keeps a Kano heatwave and a Cape Town heatwave comparable without pretending they have the same temperatures.

Transition risk uses the four NGFS scenarios. Carbon prices along each path are applied to a counterparty’s emissions to give a carbon cost, which, with the scenario’s demand and price effects, gives a revenue impact and then a credit impact. Physical shocks and transition scenarios can be combined in one stress run and compared side by side.

Results chain from hazard to loss, and each link is visible in the console and in the scenario report:

1. Hazard at the counterparty’s sites, under the chosen shock and scenario.
2. Operating impact: disruption, damage and carbon cost, expressed against revenue and earnings.
3. Probability of default: the stressed financials move the counterparty’s PD from its baseline.
4. Expected credit loss: the stressed PD combines with loss given default and exposure at default in the IFRS 9 sense.
5. CET1 capital: the additional credit losses across the book are carried to the capital ratio.

Runs are marked official or exploratory, so trial runs never mix with the figures you put before a committee.

• Ranges, always. A central value is shown with a range wherever one exists: flood depths, PD uplifts, ECL and CET1 impacts alike.
• Ensembles, not a single model. Projections use several CMIP6 models; the spread between them is drawn as a band, and the central value is never shown without it.
• Partial years flagged. If the most recent year of observations is incomplete, it is marked as partial and kept out of comparisons that assume a full year.
• Scenarios compared, not averaged. Pathways are shown side by side; we do not blend them into one “expected” future.

Some figures are not observations. A terrain model may be a stand-in until a better DTM is published for an area; a demonstration book is synthetic; the charts on this website are illustrations. ecosphere never lets these pass as real. The label travels with the data into the console, the data files and the reports.

Every delivery is validated against a published data contract: the tables, fields, units, permitted ranges and place codes a delivery must meet. You can read the contract before you build on it, and a delivery that fails it is not published.

Deliveries are versioned. A stress run records which data version it used, so you always know which data an official result was built on, even after newer data has been published, and two runs can be compared knowing exactly what differs between them.

Before a delivery reaches the console, a second person, not its author, reviews it. Validation catches what a machine can check; review catches what it cannot, such as a plausible-looking number in the wrong place.