ProcessSustainability Studio (Guardian)
From written methodology to Guardian policy, step by step
A Guardian policy is a methodology rewritten as data, roles and rules a machine can enforce. Getting there means breaking the methodology into parameters and equations, modelling evidence as versioned schemas, binding each role to a decentralised identifier, wiring blocks for submission, review, calculation and minting, connecting MRV data and testing with awkward cases. This page walks through each step and the decisions it raises.
On this page
- What digitising a methodology changes, and what stays with people
- The path from methodology text to a traceable token
- Seven working steps to a published policy
- Mapping methodology elements to Guardian constructs
- Awkward cases to test before publication
- Who may change a published policy, and how
- Hypothetical: digitising a cookstove methodology
- Questions and answers
- Sources
What digitising a methodology changes, and what stays with people
A methodology tells a project developer what to measure, how to calculate the claimed reduction or removal, how often to monitor and what a verifier must check. Digitising it in Guardian turns those instructions into a workflow that collects each item as structured data, applies the calculations identically every time and records every submission and approval against the identity that made it.
It does not change the methodology. The standard body still owns the rules, accredited verifiers still exercise judgement and the registry still decides whether to issue. A policy that departs from the methodology text is a defect even when it looks more efficient, so the methodology owner should review the policy's logic as well as its outputs.
The path from methodology text to a traceable token
- Methodology text
Rules, equations and monitoring requirements as the standard body publishes them.
- Requirements register
Every parameter, equation, cadence and evidence type listed in one place.
- Versioned schemas
Structured definitions of each document the workflow collects.
- Policy workflow
Blocks for submission, review, calculation, approval and minting, bound to roles.
- Dry run
Simulated execution with realistic data and edge cases before publication.
- Token and trust chain
Issued units linked back to the credentials and approvals behind them.
Seven working steps to a published policy
Decompose the methodology
List every parameter with its unit and source, every equation with its inputs, the monitoring frequency and the evidence a verifier expects, such as meter logs or laboratory certificates. Mark which values the methodology fixes, which are chosen at registration and which are measured each period.
Model the data as schemas
Turn each document the methodology implies, such as a project description or monitoring report, into a schema with typed fields, units and validation rules. Completed documents become verifiable credentials, so field names become part of the evidence; choose them carefully and version them.
Define roles and bind identities
Name the roles the workflow needs, typically the registry, the project developer and the validation and verification body. In Guardian, roles separate users by responsibility, and block permissions set by role decide which blocks each user can see or use1; each participant acts through a DID.
Assemble the workflow blocks
Build the sequence of registration, validation, monitoring submissions, verification, calculation and the mint step that issues tokens on Hedera Token Service. Where several organisations act in the same role but must not see each other's documents, use groups, which limit document access to their members1.
Connect MRV data
Decide for each parameter whether it arrives from a sensor feed, a laboratory system, a remote-sensing provider or a manual upload. Add data-quality flags for gaps, outliers and unit mismatches, so reviewers see problems before approving rather than after.
Dry-run with awkward cases
Run the policy in Dry Run mode, which simulates execution without affecting the live environment2, using realistic data across several monitoring periods. Spend most of the effort on the cases listed further down.
Publish and open the trust chain
After publication, each issued asset's history can be traced through the verifiable presentations Guardian generates3. Agree how buyers and auditors will reach that view and which documents each may see.
Mapping methodology elements to Guardian constructs
Each row is a translation decision. The third column is where most design time goes.
| Methodology element | Guardian construct | Question to settle |
|---|---|---|
| Parameters and defaults | Schema fields with types, units and validation | Which values can a developer edit, and which does the methodology lock? |
| Equations | Calculation blocks inside the workflow | Are rounding and unit conversion specified, or left to interpretation? |
| Monitoring frequency | Repeated monitoring-report submissions per project | How are partial or late periods handled? |
| Evidence requirements | Files referenced from credentials and stored on IPFS | What may be visible to buyers, and what stays with the developer? |
| Responsible parties | Policy roles and groups, with participants acting through DIDs | Can one organisation hold two roles, and should it? |
| Issuance decision | An approval followed by a mint step | Who gives final approval, and is it ever automatic? |
Awkward cases to test before publication
Happy-path tests prove little. These cases expose most policy defects before real projects meet them.
Who may change a published policy, and how
Treat a published policy as a controlled document. A change should start from a written request naming the methodology clause or defect involved, pass review by the methodology owner and the registry, and be released as a new version rather than an edit in place.
Decide in advance how existing projects move between versions. Some programmes keep projects on the version they registered under until renewal; others migrate at the next monitoring period. Either way, the record for any issued unit should show which policy version produced it, so a buyer can tell the rules apart years later.
Hypothetical: digitising a cookstove methodology
Questions and answers
Can we reuse a policy from Guardian's library of examples?
Often as a starting point. Guardian's documentation includes a curated library of policy templates and examples4. Check that any policy you adopt matches the exact methodology version you operate under, review every calculation against the published text and confirm the roles suit your programme. Treat an imported policy as someone else's code and test it with your own data before relying on it.
How are calculation errors corrected after tokens have been issued?
Not by editing history. The issued tokens and the records behind them stay as they are; the registry decides on a correction, such as withholding or cancelling units, a documented adjustment or recalculation in the next period, and the policy records that decision with its reasons. Agree the route with the registry and methodology owner during design, because a policy without one forces manual workarounds later.
Does Guardian replace a carbon registry?
It can serve as a registry's issuance workflow and evidence record, but it does not replace the registry's governance: its rules, its approval of verifiers, its listing decisions and its standing with buyers. Some registries may run Guardian at the core of their operations; others connect it to existing registry software. Either way the registry remains the party that decides on, and answers for, issuance.
Sources
- Policy roles and groups — Guardian documentation · checked 10 October 2026
- Dry Run mode — Guardian documentation · checked 10 October 2026
- TrustChain — Guardian documentation · checked 10 October 2026
- Library of policy examples — Guardian documentation · checked 10 October 2026