System boundaries: well-to-wheel, cradle-to-gate, EN 15804

A system boundary says which stages of a life cycle a factor counts. Two factors for the same fuel can differ by 15 % or more only because one covers the burn and the other covers the burn plus the fuel's supply chain. Every row in the data names its boundary in system_boundary, so you can check it before you compare or add. Every boundary, with the stages it covers and what each includes by default, is one download: system-boundaries.xlsx.

The terms you will meet#

For a fuel, well-to-use is upstream plus combustion. For delivered electricity, it is generation, the generation's upstream and the network losses, plus the upstream of the losses (transmission_distribution_upstream). Where an electricity publisher prints generation only, open-climate.ai adds those three legs as marked estimates (Estimated electricity legs). It never includes building the power plant or the vehicle: a boundary that does is energy_lifecycle.

The families#

Every boundary code is grouped three ways, and the three answer different questions. boundary_preset says how much of the life cycle the code covers, and it is what the boundary filter groups by. boundary_role says whether a number on that code may be reported alone: whole, part, credit or unknown. boundary_family records which taxonomy the code comes from: where it was defined, not how much it covers. The 55 codes fall into five families:

• energy_stage (8 codes): stages of an energy chain, such as combustion, upstream_fuel, generation, fugitive and well_to_use.
• lifecycle (13 codes): whole or partial product life cycles, such as cradle_to_gate, cradle_to_consumer, cradle_to_grave and end_of_life.
• asset_stage (16 codes): the EN 15804 modules A1 to C4, used by construction product EPDs.
• contribution (17 codes): one slice of a product's footprint, such as agriculture, transport or packaging, plus module D and avoided-burden credits.
• unknown (1 code): the publisher states no boundary and its structure does not reveal one.

The boundary is the publisher's own declaration where they state one. Where they do not, it is read from the structure of their data, never guessed from the activity name.

A preset is not a finer or coarser family: the part presets group the EN 15804 modules together with our own contribution slices, so upstream_slice holds A1 and A2 beside agriculture and inputs. To keep only numbers that stand on their own, filter on boundary_role = 'whole', never on the family.

In factor search, filter one code with bcode, for example combustion factors, or a group of codes with bpreset, for example whole energy chains.

Watch out. A merge can retire a code, and a filter on a retired one fails quietly. September folded well_to_wheel into well_to_use, so WHERE system_boundary = 'well_to_wheel' matches nothing rather than erroring, and an aggregate over nothing reads like a zero. Take the surviving codes from the table above or from the view itself, and see the four kinds of change.

Worked example: butane#

ADEME publishes butane for Europe, per kWh, as a well-to-use total with its two parts. The 2014 edition, whose window has no start and closes at 2018, so it answers for any accounting year up to and including 2018:

0.22968 plus 0.03780 is exactly 0.26748. The two parts carry parent_relation = sums_to_parent, which is the data's promise that they add up to the total.

Use the parts to split your inventory by scope: combustion goes to Scope 1, upstream to Scope 3 category 3. Use the total when you only need one number. Never add a part to its total: that counts the same emissions twice.

The current edition (reference year 2019) prints rounded values, 0.23 and 0.0392 for a total of 0.269. Search ADEME butane factors to see both.

Watch out. DESNZ also publishes butane, with a UK well-to-use total of 0.26843 kg CO2e per kWh. The number is close to ADEME's, but check co2e_basis as well as the boundary before treating them as the same thing: see Biogenic carbon.

EN 15804 modules#

Construction product EPDs report their footprint by module, under the European standard EN 15804:

ÖKOBAUDAT stores each EPD as one total with its modules as children. For the product ALT 100:

• the total, cradle_to_grave_embodied (every module except the use stage), is 1250.991 kg CO2e per unit;
• it is the sum of cradle-to-gate (A1 to A3) 1240, A4 0.481, A5 0.432 and end of life 10.078;
• end of life is itself C2 0.228 plus C3 9.85;
• module D is -294, with parent_relation = reported_beside_parent.

Module D sits beside the total and is never added to it. The standard requires it to be reported separately.

When an EPD declares a set of modules that is neither a full cradle-to-grave nor the embodied cut, its total is epd_total: "every module this EPD declared", with the modules listed on the factor.

Which boundaries each library uses#

What the boundary does not tell you#

• Carbon pools. Whether biogenic CO2 or land-use change is counted is not a boundary question. Read co2e_basis and the gas columns: see Biogenic carbon.
• Absent stages. boundary_scope lists what a boundary includes, may include and excludes. A stage it does not mention is "not established", not "excluded".

Related#

• system-boundaries.xlsx: every boundary code, its family, the stages it covers and its default scope
• Parents, children, double counting
• Sum a decomposition
• Glossary: system boundary and sums to parent
• Market-based vs location-based electricity