Key MRV Concepts

This API is for supplying data about Carbon Removal activity to Isometric for the purpose of verification.

​

Confidentiality

Until resources are submitted as part of a GHG statement, they are visible only to members of your organisation. After this point, they are visible to the verifier assigned to the GHG statement. Once credits have been issued, removals are added to the public registry, and associated resources are visible publicly, with the exception of source documents.

​

Key Resources

The main resources in the API are sources, datapoints, components and removals.

​

Sources

Sources represent a piece of evidence for a particular value used in carbon accounting calculations. When creating a source with the POST /sources endpoint, a signed upload URL is returned which can be used to PUT a file to.

Source documents are private, and only shared with the verifier assigned to a related removal. Other information associated with a source, such as its display name, is visible publicly once the removal is on the public registry.

When a Source is added to a Datapoint that is related to a Removal which is part of a submitted GHG statement, the verifier won’t immediately be notified, but they will immediately have access to the source documentation. In this scenario notify the Isometric engineering team so that we ensure that the verifier is aware.

​

Datapoints

Datapoints represent any value used in carbon accounting calculations. When creating datapoint, sources should be referenced to provide evidence for the value used.

A standard deviation should be provided if the datapoint is to be included in the variance propagation method of uncertainty analysis. All datapoints are considered statistically independent for the purpose variance propagation, although if a datapoint is used twice within a removal calculation, this dependence is captured.

​

Components

Components represent physical activities whose CO₂e flux needs to be accounted for. Components are created from component blueprints that contain sets of equations used to calculate a transfer of CO₂e into or out of the atmosphere. A list of component blueprints can be found by calling the GET /component_blueprints endpoint. A blueprint defines a set of input that are the datapoints to be used in the calculation. For instance, a transport emissions blueprints would ask for datapoints representing a distance, mass and carbon intensity.

When creating a component from a blueprint, the blueprint must be specified, as well as a list of datapoint IDs that match with the expected blueprint inputs.

​

Removals

Removals represent a series of activities that result in CO₂e being removed from the atmosphere. The carbon accounting of a removal typically contains sequestrations, counterfactuals and activities (emissions). A removal must follow a process defined in the Isometric system.

A process contains a series of steps which are high level descriptions of different terms in the carbon accounting. Each step contains components which represent the actual physical activities. For instance, a bio-oil sequestration process may contain a bio-oil transport step. This step could in turn, contain multiple components if, for instance the bio-oil was transported multiple times by multiple different transport modes. Components can also be partially attributed to removals, if the activity the component represents contributed to multiple removals.

The final uncertainty discounting is done on the removal level - the API will return the CO₂e removed with and without discounting.

​

Feedstock Types

Many carbon removal methods involve a feedstock, for instance the biomass feedstock in BiCRS or silicate rock in enhanced weathering. Feedstock types are used to describe the feedstock used in a removal. When creating a removal, a feedstock type can be optionally specified so that Isometric and verifiers can see which removals use which feedstocks. This is important if different feedstocks are used in a single GHG statement.

​

Updating resources

Our API supports updating resources via PATCH endpoints. These operations will create new versions of the resource, and also propagate changes upwards to any parent entities. For example, updating a datapoint that is already used in a component will update the component as well. If that component is used in any removals, those removals will likewise be updated. Due to this behavior, we recommend that PATCH operations are run sequentially—instead of in parallel—to avoid concurrency issues caused by a resource being updated in multiple places.