Dependencies Assessment
Biodiversity dependency assessment methodology using ENCORE in Darwin.
Methodology
- ENCORE dataset (2024 update) on dependency materiality ratings for economic activities is used for materiality scores and value chain mapping (upstream and downstream).
- We link this dataset to 2 categories of collected data managed within the platform: monetary data and product data (including commodities).
- Regarding monetary data, the mapping between EXIOBASE products and ENCORE economic activities stems from combining the mapping of EXIOBASE industries to ENCORE economic activities (provided directly by ENCORE) with the mapping of EXIOBASE industries to EXIOBASE products (provided by EXIOBASE).
- For product data (and commodities), the mapping between ecoinvent products and ENCORE economic activities was carried out based on the sectoral product classification provided by ecoinvent. For Agribalyse mapping was done manually.
- ENCORE's modeling of the economic activities value chain, which includes 2 tiers upstream and 2 tiers downstream, has been incorporated.
- As a result, for each product or monetary data point, materiality ratings levels for the 25 ecosystem services, covering both direct operations (Scope 1) and indirect operations upstream and downstream (5 sectors in Tier 1 and 25 in Tier 2) are available, totalling 1525 dependency materiality ratings for each data point.
- Dependency assessment is conducted at the level of each entity. The maximum dependency rating considering all entity's data points is returned by scope and by ecosystem service.
- At the root entity level (the highest-level entity in the project), a heatmap view is provided to easily identify the main issues within the organization.
Score methodology
For each ecosystem service (ES) × Scope pair, the dependency score is the maximum ENCORE materiality rating across all the entity's input points for that pair. This score is recomputed live as the impact filter slider (below) is moved, keeping only the input points that survive the selected impact cut-off.
Filtering input points by impact
The Dependencies radar carries an impact filter slider that narrows the analysis from all input points down to only the most impactful ones. It lets users separate dependencies driven by a company's material activities from those that merely surface through marginal, low-interaction data points. The radar recomputes live as the slider moves.
The slider has four positions, each keeping a progressively smaller, higher-impact subset of input points:
| Position | Input points kept | Impact cut-off |
|---|---|---|
| All | Every input point | none |
| Top 50% | Impact ≥ median | P50 |
| Top 25% | Impact ≥ third quartile | P75 |
| Top 10% | Impact ≥ top decile | P90 |
How it works:
- Impact as a proxy for interaction with nature. Each input point carries the environmental impact it generates on the given scope (from the impact assessment). This impact is used as a proxy for how strongly the underlying activity interacts with nature — the filter removes the noise of marginal activities so the radar reflects the dependencies that matter most.
- Score at each position. For each ecosystem service × scope pair, the score at a given slider position is the maximum ENCORE materiality rating among the input points that survive the filter. As input points drop out, the maximum can only stay equal or fall — tightening the slider never raises a score (the deformation is monotone).
- Consistent cut-offs across the radar. The cut-offs are nearest-rank percentiles (P50 / P75 / P90) of the distinct input-point impact distribution, computed once per (entity, scope) and shared across every ecosystem service of that scope. This keeps a slider position globally consistent across the radar: "Top 25%" means the same impact threshold for every service in that scope. Because the cut-off is taken over the distinct impacts, the exact share of points kept can differ slightly from the labelled percentage when several input points share the same impact value.
- Marginal & fallback points. Input points with no associated impact (e.g. fallback rows) are treated as impact-0 candidates: they count only at the All position and drop out as soon as any filtering applies.
- Comparability. Scores are comparable within a scope only, not across scopes — each scope has its own impact distribution and cut-offs.
A radar that stays flat across slider positions is not a bug: when the highest-impact input points are also the highest-scoring ones, the maximum ENCORE rating never drops as lower-impact points are filtered out.
Where the materiality comes from (sources and precedence)
A dependency materiality score is resolved from up to four sources, applied in a fixed order of precedence. This matters most for sites that carry little or no collected data of their own.
1 — Declared data wins. When a site has its own product or monetary data points, its materiality comes directly from them (mapped to ENCORE as described above). Declared data always takes precedence over any fallback, scope by scope.
2 — Fallbacks, when declared data is missing. When an entity has no product or monetary data for a scope, it falls back to a default materiality — and which default applies depends on the kind of entity:
- An organisation-level entity (a company root or organisation unit) with a declared sector → the ENCORE materiality of that sector, matched through the EXIOBASE monetary classification.
- A site → the curated default materiality for its site type (e.g. Offices, Factory or powerhouse, Mining). A site carries a site type, never a sector.
These two fallbacks are mutually exclusive because they apply to different kinds of entity: a sector is declared only on organisation-level entities, while a site only ever carries a site type. So a site with a site type always resolves through the site-type defaults, whatever its parent organisation's sector.
A site does not inherit its parent organisation's sector for this purpose — a site's own materiality default is always its site-type default. The sector default applies to the organisation-level entities (root / units) that carry a sector.
The site-type defaults give a baseline dependency materiality for each canonical site type — a reasonable estimate for sites described only by their type (an office is not as materially dependent as an operational industrial site), pending more precise product or monetary data. They apply across all scopes (direct, upstream and downstream), so a site with no declared data still gets a Scope 3 dependency materiality. What differs by scope is how the baseline is built: the Scope-1 (direct) dependency slice is the hand-curated, validated matrix, while the upstream and downstream rows are derived from EXIOBASE rather than curated.