Attributing components

​

Why Use Attribution

Attribution enables precise tracking of component contributions across the carbon removal process.

A component represents a certain amount of CO₂e transferred during a Carbon Removal process. The result of each component can be attributed to specific activities or groups of activities in the ways outlined below. This attribution determines how its carbon impact is distributed.

Attribution allows us to:

• Track how components contribute to multiple removals.
• Distribute emissions across different accounting boundaries
• Enable flexible allocation of carbon impacts
• Maintain accurate carbon accounting across the system

Our multi-level attribution system ensures accurate, flexible, and verifiable carbon accounting while supporting complex project structures.

​

Attribution Levels

​

Component Level Attribution

The most granular level of attribution. A component’s emissions can be split precisely between different removals.

​

Key Concepts

• Components can be partially attributed (like the below example)
• Total attribution of a single component cannot exceed 100%
• The Removals that a component is attributed to can exist in different GHG statements if necessary.
• Attribution is tracked via datapoints with full versioning and audit history. We encourage the submission of evidence documents so that the attribution can be verified accurately.

​

Example

A transport leg might have been applicable to multiple removals, with:

• 60% attributed to Removal A
• 40% attributed to Removal B

Our system would allow for the creation of a singular Transport component, which can then be attributed between Removal A and Removal B, without having to duplicate the component itself.

​

API Example

You can firstly create a component as usual via the following endpoint:

POST /components

In order to attribute a component between specific Removals, you will need to create an attribution Datapoint, which will represent how much of the Component you would like to attribute to a given Removal.

You’d create this using the following endpoint:

POST /datapoints

The payload would look something like:

{
  "description": "My description",
  "display_name": "My datapoint",
  "measured_at": "2023-11-07T05:31:56Z",
  "measurement_location_id": "pfx_1H0G39139CF0DZB2",
  "quantity": {
    "magnitude": 50,
    "standard_deviation": null,
    "unit": "PERCENT"
  },
  "source_ids": [
    "pfx_1H0G39139CF0DZB2"
  ],
  "supplier_reference_id": "my_reference",
  "type": "CONSTANT"
}

The quantity of the Datapoint is what would represent the attribution of the Component to the Removal. You can supply percentage attribution quantity, as given in the example.

Then, when creating the Removal, you can include the following:

{
  // ...
  "steps": [
    {
      "components": [
        {
          "attribution_factor_datapoint_id": "dtp_1H0G39139CF0DZB2",
          "component_id": "cmp_1H0G39139CF0DZB2"
        }
      ],
      "process_step_key": "transport"
    }
  ],
  // ...
}

This will mean that only the portion of the component determined in the attribution Datapoint will be attributed to the Removal.

​

GHG Statement Level Attribution

Manages how GHG statement-level emissions are distributed across the Removals in the GHG statement. Any GHG statement level emissions would be evenly distributed across all removals within the statement. This ensures consistent accounting within the statement boundary and simplifies verification.

​

Key Concepts

• Components within a GHG statement are evenly attributed across its Removals, regardless of individual Removal size.
• Maintains consistent accounting within statement boundaries
• Ensures complete attribution of all GHG statement emission components

​

Example

A GHG statement has 3 Removals, with the following sequestration amounts:

• Removal A: 1000tCO₂e
• Removal B: 2000tCO₂e
• Removal C: 3000tCO₂e

The GHG statement has a total of 6000tCO₂e sequestered. If a Supplier wants to account for their office energy use over the entire statement period, they can add a GHG emission component to the GHG statement with a size of 600tCO₂e. It would be split between the Removals evenly, with each Removal accounting for 200tCO₂e.

This would result in the following totals for the Removals:

• Removal A: 800tCO₂e
• Removal B: 1800tCO₂e
• Removal C: 2800tCO₂e

​

API Example

If you have a GHG statement that you’d like to create an emissions component for, you can simply do so via the API:

POST /ghg_statement_components

This component will automatically be evenly distributed across all Removals in the GHG statement.

​

Project Level Attribution

Manages how project-wide components are distributed across GHG statements. This uses proportional distribution based on the net sequestration ratios of each statement relative to the total project output. Total project output is the expected output of a project over it’s lifetime, which must be provided when a Project is added to Isometric’s system.

This method of attribution is useful in the cases of large up-front emissions which aren’t attributable to a singular removal activity. For example, facility setup or machinery acquisition.

The attribution is automatically applied to any existing unverified GHG statements upon Project emission creation, or when a new GHG statement is created when Project emissions already exist.

​

Example

Project A has the expected lifetime output of 10,000tCO₂e. There was a facility setup emission of 1000tCO₂e which isn’t attributable to a single Removal activity, and therefore should be spread between all Removals in the Project. The Supplier creates a GHG statement which has a total size of 5000tCO₂e before any Project-level emissions are applied to it.

Our system would then automatically compute the following proportion of the facility setup emission to be applied to the GHG statement:

5000tCO₂e / (10000tCO₂e + 1000tCO₂e) = 0.4545

This means that (1000tCO₂e * 0.4545 = 454.5tCO₂e) of the Project emission would be applied to the created GHG statement. Each Removal within the GHG statement would receive an even split of this portion of the emission, as documented in the section above.

​

API Example

If you have a Project that you’d like to create an emission component for, you can simply do so via the API:

POST /project_components

As part of this payload, you select an amortization strategy - at the moment, we support a strategy based on estimated lifetime project output. This means that the emission will be split across all GHG statements in the Project based on the proportion of the expected output that each GHG statement represents.

When you create a Project component, its emissions will automatically be split across any unverified GHG statements in that Project. All verified GHG statements will not be modified as they are immutable.