> ## Documentation Index
> Fetch the complete documentation index at: https://docs.isometric.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Key Registry Concepts
> Key concepts in the Isometric Registry including entities, credits, orders, issuances, deliveries, retirements, and credit batch management
## Introduction
This page defines concepts found in the Isometric Registry, and used in the [Registry API](/api-reference/registry/registry-introduction).
For a broader understanding of the requirements and processes governing the Isometric Registry, please refer to the [Isometric Standard](https://isometric.com/standard).
## Key Concepts
### Entities
#### Supplier
An entity that removes carbon dioxide from the atmosphere so that it can be stored durably and sells this service to Buyers.
#### Project
An activity, process or group of activities or processes that alter the condition of a Baseline, resulting in [Removals](/user-guides/certify/key-certify-concepts#removals).
#### Buyer
An entity (usually a corporation, but can also be an individual or a government entity) that purchases CDR, often with the purpose of retiring CDR credits to make a carbon neutral or net-negative claim.
#### Beneficiary
An organization benefiting from the Removal claim afforded by a Credit. This may be the current holder of the Credit at the time of Retirement, or an organization specified by the Credit account holder during the Retirement procedure.
### Credits
A credit is a publicly visible, uniquely identifiable Credit Certificate Issued by a Registry that gives the owner of the Credit the right to account for one net metric tonne of Verified CO₂e Removal.
In the case of the Isometric Standard, the net tonne of CO₂e Removal comes from a Project validated against a certified Protocol.
#### Order
A set number of tonnes that a buyer purchases from a supplier in a given contract. An order is logged in the Isometric registry once a buyer has also agreed a verification fee with Isometric.
#### Issuance
Once a Verified Removal has taken place, Isometric issues credits to the account of a Supplier, enabling them to deliver credits to their buyers with pending orders.
#### Delivery
The outcome of a supplier apportioning removals into orders to fulfill their buyers' purchases. A removal can only be delivered after it has been verified.
#### Retirement
Retirement is a mechanism where a Credit's state is finalized in order to make a public claim. On retirement, Isometric issues a retirement certificate and the credit can no longer be updated. This ensures that once the net tonne of CO₂e represented by the retired Credit is used towards an accounting activity, it is not double counted.
Credit batches will have the status `RETIRED` after retirement.
#### Buffer Pool
The Buffer Pool is a pool of credits that are held in an account matched to a Supplier to manage reversal risk. Buffer pool credits may be cancelled in the case of a reversal.
#### Credit Vintage
The Credit Vintage is the calendar year in which the underlying carbon removal or climate impact associated with a Credit occurred, as determined by the end date of the relevant removal or reduction. This will commonly, but not necessarily, correspond to the year of Credit issuance, as issuance may occur at a later date due to reporting or verification timelines.
Where a method supports granular reporting data, or growth or process modelling, across a multi-year reporting period, Credits may be split across multiple vintage years to reflect the calendar year in which each portion of removal or climate impact occurred. Where removals or climate impact cannot be robustly attributed to individual calendar years, the vintage is assigned based on the end date of that reporting period.
### Credit Batches
A Credit Batch is a grouping of 1 or more credit units, where each credit unit represents 1kg of CO₂e removed.
When credits are initially Issued, they will be batched together with status `ACTIVE`. When subsequent transactions are made using these credits,
including deliveries, retirements and transfers, a batch might be split to make this possible.
All credits in batch will always have the same initial Supplier, Project and Issuance.
#### Credit Batch Splitting
If the quantity of credits in a transaction request (delivery, transfer or retirement) does not match the full size of the submitted credit batches,
the batches submitted will be split in order to transact the exact credit amount requested.
When a credit batch is split, its status will be updated to `SPLIT` and it can no longer be interacted with.
Two *child* batches representing the two halves of the split are created with an `ACTIVE` status.
For API users, child batches will have a `parent_id` set pointing at the originally split batch.
From the parent split batch, you can find its two children via the `left_child_id` and `right_child_id` fields.
See the [Credit Batch endpoint](/api-reference/registry/credit-batch) for more details.
