Principles
The Isometric Protocol versioning policy is based on the following principles:- Consistency
- Elimination of ambiguity
- Backwards compatibility
Definitions
Materiality
For the purposes of Protocol versioning, material changes are defined as those which affect how validations and verifications are conducted, or their outcomes. If a change requires Validation and Verification Bodies to modify their approach, methods, or decisions, it is considered material.Version format
Isometric uses theMAJOR.MINOR.PATCH version format, where three non-negative integers denote the full version of the corresponding Protocol or Module.
Major version
A new major version represents a very significant departure from a previous version. It introduces material changes to the validation and verification rules. Major versions are typically used to remove support for old practices.Minor version
A new minor version represents an evolution, rather than a very significant departure, from a previous version. Like a major version, it introduces material changes to the validation and verification rules. Minor versions are typically used to:- Introduce support for new practices
- Adapt to scientific or legal developments
- Systematize existing rules
Patch version
A patch version is used solely to improve the contents of a Protocol or Module, without introducing any material changes to the rules defined in it. Typical reasons for a new patch version are to:- Fix errors, such as typos or inactive links
- Clarify existing wording
- Add or modify examples
Modularity
Isometric Protocols are built from reusable components called Modules. Modules ensure that related rules are defined consistently across all Protocols. Each Protocol minor version specifies exactly which Modules it uses and locks in their specific minor versions. Once certified, this combination never changes, so the Protocol minor version number alone determines the complete set of rules applicable to any project. New Module minor versions only take effect when incorporated into a subsequent Protocol release. This means that new Module rules only apply when the Protocol itself updates and projects adopt the new minor version.Version lifecycles
Protocol version lifecycle
Each Protocol minor version progresses through distinct lifecycle stages that determine how projects can use it. These stages govern validation and verification activities. Draft: Under consultation (private or public). Content may change materially, including changing modules and their minor versions. Certified - most recent: Projects normally perform validation against this version, unless qualified for an earlier minor version. Certified - superseded: A version becomes superseded when a newer minor version is certified. Projects can still use superseded minor versions for verifications. Certified - legacy: A version becomes legacy when the adoption deadline of any subsequent minor version is reached. Projects cannot use legacy versions for verifications and must first adopt a non-legacy version.Backwards compatibility mechanisms apply whenever a project adopts a new Protocol minor version.
Module version lifecycle
Module minor versions have only two lifecycle stages: Draft: Under consultation (private or public). Content may change materially. Certified: Available for use in certified Protocol minor versions. Modules do not have a formal end-of-life process, unlike protocols. Modules are phased out by no longer being used by protocols.Consultations
Every material change to validation and verification rules will undergo a public consultation. As a result, only major or minor releases may undergo a consultation. Consultation does not occur for patch versions as those changes are immaterial.Module consultation
Every new major or minor version of a Module will undergo a public consultation.Protocol consultation
Every new major version of a Protocol requires public consultation. Every new minor version of a Protocol requires public consultation by default. However, Protocol consultation may be skipped when all of the following conditions are met:- The scope of changes is limited to upgrading, introducing, or removing a Module or Modules
- Any changes to the Protocol itself are limited to the scope of the relevant Module or Modules
- Each relevant Module’s public consultation stipulated how it would affect this Protocol
- The adoption deadline is equal to or longer than the default of 12 months
Consulting existing projects
Projects will be notified and invited to participate in public consultations for new minor versions of Protocols and Modules that affect them. This applies to projects operating under a Protocol when:- A new minor version of that Protocol is released
- A new minor version of a Module used by that Protocol is released
Adoption requirements
Each project is associated with up to 2 Protocol minor versions at any point in time:- Baseline: The Protocol minor version that the project was initially validated against in the current crediting period. This version establishes the baseline for grandfathering exemptions.
- Current: The Protocol minor version that the project currently operates under. This version determines the rules and Module versions applicable to the project’s ongoing operations, verifications, and credit issuance.
Backwards compatibility mechanisms apply whenever a project adopts a new Protocol minor version.
Patch version adoption requirements
Patch versions take effect automatically upon release. Since they contain no material changes to validation or verification rules, no project action or enforcement is required. Projects automatically operate under the latest patch version of their current minor version.Minor version adoption requirements
When a new Protocol minor version is certified, existing projects have 12 months to adopt that Protocol minor version, or a more recent one, for subsequent verifications. When this adoption deadline is reached, all previous minor versions become legacy and can no longer be used for verification and credit issuance. In exceptional circumstances, a different adoption period may be specified in the updated Protocol minor version. A period shorter than the default of 12 months will make the Protocol change subject to public consultation.Major version adoption requirements
Existing projects are not required to adopt a new major version of a Protocol until they seek renewal of their crediting period.Backwards compatibility
Several mechanisms ensure that projects can maintain practices established at project validation, regardless of future changes to Protocols.No requirement to adopt new major versions
New major versions of a Protocol do not need to be adopted until the project seeks renewal of its crediting period.Grandfathering exemptions
Projects can claim grandfathering exemptions against all new requirements. New requirements are defined as those not present in the Protocol minor version which the project was initially validated against in the current crediting period. This permits projects which have already operated under a specific minor version to continue practices permitted by it. Exemptions cannot be claimed against changes to accounting and quantification formulae or their integral dependencies. Grandfathering exemptions are valid until the end of the current crediting period, and cannot carry over to a subsequent crediting period. Details of grandfathering exemptions will be displayed publicly, subject to commercially sensitive information being redacted.Retaining existing validation status
The entire project and its validated assets remain valid when the project adopts a new Protocol minor version — no revalidation is required. Credit issuance is backwards compatible by default - assets validated against a previous Protocol minor version can continue to be used for credit issuance. Exceptionally, when updated accounting or quantification formulae have integral dependencies on asset data, those assets may need to be validated against a more recent Protocol minor version to issue credits. Any such cases will be clearly stated in the Protocol minor version’s release notes and will need to undergo public consultation. During this validation, grandfathering exemptions can be claimed for all other new requirements.Frequently asked questions
How often are new versions released?
New patch versions are released as needed for both Protocols and Modules. Isometric will regularly release new minor versions of Protocols to incorporate new approaches, updated science, and upgrade to new Module versions. Protocol minor releases are expected to happen no more frequently than every 6 months, and will follow a regular schedule where appropriate. There is no target release cadence for minor versions of Modules. However, new minor versions of Modules are applicable to projects only when they get incorporated into a subsequent Protocol version. There is no set cadence for the release of new major versions of Protocols or Modules, but we expect this to be infrequent.When are new Module versions incorporated into Protocols?
A new Module minor version will normally be incorporated into a Protocol during the next minor release of the Protocol. A new Module major version may be incorporated into a subsequent Protocol minor release, but does not need to be. Module major version upgrades may be reserved for selected Protocol major version series.What Protocol version must a new project validate against?
Every new project must validate against the most recent certified major and minor version of the relevant Protocol. This is unless it has qualified for a previous minor version. Qualifying for a Protocol version means a project can perform initial validation against that version, even if it is not the most recent one. It happens when any of the following events occurs:- Execution of Isometric Supplier Agreement Project Appendix
- Commencement of project design pre-screen
- Commencement of project design validation
Why are projects required to adopt new Protocol minor versions?
Requiring adoption of new minor versions serves three key purposes: Consistency in carbon accounting: All credits issued during the same timeframe use the same accounting and quantification methodologies, ensuring comparability across projects. Streamlined crediting period renewal: Projects that have assessed their compliance status against current rules can more readily become ready for renewal, as continuously discovering implementation gaps reduces renewal uncertainty. Demonstrating forward compliance: Projects that already meet new rules can demonstrate their compliance with the latest requirements in assessed areas. The grandfathering exemption system ensures projects aren’t forced to make changes that would be operationally difficult or expensive, while still maintaining the benefits of consistency.As a project developer, do I need to adopt each new Protocol minor version one-by-one?
No, projects normally have 12 months to adopt a Protocol minor version or newer. This means that if a newer minor version is released during the adoption period, a project can go directly to it - skipping intermediate versions. In general, projects can upgrade to any more recent non-legacy version, but cannot downgrade to an earlier version. This ensures that even if the release cadence of Protocols is more frequent than annual, projects do not need to go through the process of adopting a new Protocol minor version more frequently than once per year. To avoid delays in subsequent verifications, we recommend that projects begin the process of adopting a selected new Protocol minor version no later than 5 months before the earliest relevant adoption deadline. Note that projects may be required to, or choose to, adopt more frequently than annually under these circumstances:- A Protocol minor version is exceptionally released with an adoption deadline shorter than 12 months (this requires a Protocol public consultation).
- A project voluntarily chooses to adopt a Protocol minor version in advance of the adoption deadline, for example to benefit from support for new practices.
Backwards compatibility mechanisms apply whenever a project adopts a new Protocol minor version.
What is the process for adopting a new Protocol minor version?
Adopting a new Protocol minor version is a simple administrative process. The project notifies Isometric of its decision to adopt a specific Protocol minor version, which then becomes the project’s current version. This administrative step establishes that all subsequent verifications will be performed according to the rules and requirements of the newly adopted version. The adoption simply updates the project’s records to reflect which Protocol version will govern future verification activities.Do projects and existing assets need to be revalidated when adopting a new Protocol minor version?
No, projects are validated once at the beginning of their crediting period. They do not lose their validation status as a result of adopting a new minor version of a Protocol. Individual assets validated under a previous minor version retain their validation status and do not need to be revalidated. However, some assets may need to be validated against a more recent Protocol minor version to issue credits - see retaining existing validation status for more details.How are new assets validated for projects with different baseline and current Protocol minor versions?
All new assets must be validated against the project’s current Protocol minor version. However, projects can claim grandfathering exemptions against all rules introduced since the project’s baseline Protocol minor version. The assets will be validated against the current Protocol minor version, with grandfathering exemptions noted if claimed.How is verification performed for projects with different baseline and current Protocol minor versions?
The Validation and Verification Body performs all verification activities according to the rules described in the project’s current Protocol minor version. This applies especially to accounting and quantification formulae. However:- The project itself, and any of the already validated assets, will have been validated against an earlier minor version of the Protocol.
- The project is able to claim grandfathering exemptions against any new requirements introduced since the version it was initially validated against.
What are the conditions for a grandfathering exemption to be granted?
Projects must submit a claim stating why a specific new requirement is difficult or expensive to meet. A grandfathering exemption will be granted provided that:- The practice or approach for which the exemption is sought was permitted under the Protocol minor version against which the project was initially validated in the current crediting period.
- The exemption claim demonstrates operational difficulty or expense in meeting the new requirement.
Why can’t exemptions be claimed against changes to accounting and quantification formulae?
Exemptions do not apply to accounting and quantification formulae or their integral dependencies to ensure consistency across projects. All credits issued during the same timeframe must use the same accounting and quantification methodologies, regardless of when a project was initially validated. This restriction ensures that:- Quantification can improve: Accounting and quantification formulae can incorporate better scientific understanding or corrections, making calculations more accurate over time.
- Credits are comparable: Using consistent formulae makes credits issued in the same timeframe directly comparable across projects.