RHIZORA · Project design
The design is the root system.
Seven stages from screening to registration, each closed by a gate. The rules come from CARTIS at a pinned version, the documents assemble from the answers already given, and every figure opens to the working behind it.
- 7
- stages, each closed by a named acceptance
- 1
- pinned methodology version a project is designed against
- 2
- people on every accepted PDD section
- ±10%
- sensitivity on the feasibility estimate
Why it exists
A carbon project is designed once and argued about for years. The screening, the estimate, the design decisions and the PDD are spread across spreadsheets, documents and email, so when a validator asks where a number came from, the answer has to be rebuilt from memory — usually by the one person who remembers.
What RHIZORA does
RHIZORA gives a project one workspace and seven stages, each closed by a gate. The developer brings facts, evidence and choices; CARTIS supplies the methodology’s rules at a pinned version; RHIZORA holds the project, runs the workflow and assembles the documents. Every figure opens to its working — the equation, the inputs, who entered them and the rule set behind them.
At work
See RHIZORA do the job
Screening
Every methodology checked, or said to be unchecked
The activity, the location, the start date and each methodology’s own facts go in once. Every candidate in the CARTIS catalogue is then checked condition by condition and comes back as pass, fail, or missing data — never as a silent assumption. The project leaves the stage pinned to one standard, methodology and version.
- A methodology CARTIS has only partly encoded waits, and says which part is missing.
- The pin is what every later stage is designed against.
Feasibility
Credits by vintage, and what moves the number
Cohorts, removal rate, survival, baseline and crediting period give an estimate by vintage. Every bar opens to its working: the equation, the inputs, who entered them, and the rule set and version behind them. A ±10% sensitivity shows which assumption the answer actually rests on.
- A formula that cannot be evaluated says so with a coded diagnostic.
- The project lead accepts the estimate before the stage closes.
Traceability
Every figure opens to its working
A number on a RHIZORA screen is never just a number. Opening it shows the equation, the inputs, who entered each one, and the rule set and version it was evaluated against — which is the same answer a validator would ask for, years later.
- A formula that cannot be evaluated returns a coded diagnostic, never a silent zero.
- The rule set is named and versioned, so the working stays readable after the methodology moves on.
Design and PDD
Answered once, assembled into the document
The methodology’s checklist is answered, evidenced, or deferred with a reason, and the boundary is taken as GeoJSON or KML with its area computed. The PDD is then assembled from those answers in the template’s order and exported to Word and PDF with a traceability annex.
- Suggested prose stays unaccepted until a person accepts it.
- Whoever drafted a section never sees Accept on it.
How it works
The seven stages
Capabilities
Everything in the box
Who it serves:
Project developers
Take a project from an idea to a registered one without losing the reasoning on the way.
Project leads
Accept the estimate and own the gate at the end of each stage.
Technical writers
Draft the PDD from answers already given rather than from a blank page.
Reviewers
Accept sections they did not draft, and return them with a note.
Verifiers
Raise findings against the sections they touch and record the opinion.
Screened against the catalogue
Every candidate methodology is checked condition by condition — pass, fail, or missing data said plainly — and the project is pinned to a standard, a methodology and a version.
A feasibility estimate that opens
Credits by vintage, built from cohorts, removal rate, survival and baseline, with a traceable working behind every figure and a ±10% sensitivity.
The methodology’s own checklist
Each required element is answered, evidenced, or deferred with a reason. The boundary is taken as GeoJSON or KML and its area computed.
A monitoring plan to hand on
Parameters with unit, frequency, method and QA/QC, exported as XLSX and JSON, addressed to SONDIS or to another provider.
A PDD assembled from the answers
Sections in the template’s order, built from what was already entered, exported to Word and PDF with a traceability annex.
Validation tracked to the section
Verifier findings are linked to the sections they touch, with a new PDD version for each round of responses.
The registration package
The chosen registry’s package, assembled, and the registry’s project id recorded when it comes back.
Principles
How it keeps its integrity
- Pin the version, then design against it.
- Every figure opens to its working.
- The drafter never accepts their own section.
- Say what is missing rather than assuming it.
Clear scope
What it isn’t
- Not the verifier
- The opinion belongs to a person outside the suite. RHIZORA records their findings and the responses; it does not issue an opinion.
- Not the rule book
- Standards, methodologies and factors live in CARTIS. RHIZORA reads them at a pinned version and never keeps a second copy.
- Not monitoring
- It writes the monitoring plan. The readings are collected in SONDIS, or in whichever system the project uses.
- Not the registry
- Issuance, serials, transfer and retirement belong to AMMONIS. RHIZORA hands over the registration package.
Built on
What RHIZORA stands on
The platform underneath, and what the work depends on outside it.
The platform
-
One platform core
The same evidence architecture the rest of the suite runs on: identity, roles, attribution and the audit trail are not rebuilt per product.
-
Rules read, never copied
Conditions, parameters and templates come from CARTIS at a pinned version, so a project designed last year still says which rules it was designed against.
-
A gate per stage
A stage closes on an explicit acceptance by a named person, not on a box being ticked somewhere.
-
Evidence stored, not recomputed
A figure keeps its equation, its inputs and who entered them, as they stood on the day it was accepted.
What it connects to
- CARTIS methodology rules
- GeoJSON and KML boundaries
- SONDIS monitoring plan
- AMMONIS registration package
- XLSX and JSON
- Word and PDF
Questions
Asked often
Where do the methodology rules come from?+
CARTIS. RHIZORA reads conditions, parameters and templates from it at a pinned version and keeps no second copy, so a project still says which rules it was designed against years later.
What happens if a methodology is not fully encoded yet?+
The project waits at that point and says which part is missing. Nothing is assumed in order to keep moving.
Can someone approve their own work?+
No. A section is accepted by somebody other than the person who drafted it, and a return carries a note.
Does it do the monitoring as well?+
No. It writes the monitoring plan and hands it on — to SONDIS, or to whichever system the project collects in.
Does it issue the credits?+
No. It assembles the registration package. Issuance, serials, transfer and retirement belong to AMMONIS.
Works with
Part of MARIS
Each product reads the climate from its own angle. With Climate Intelligence at the centre, together they cover it end to end.
Hands the monitoring plan to SONDIS for collection.
Explore →Hands the registration package to AMMONIS.
Explore →Reads the methodology’s conditions, parameters and templates at a pinned version.
Explore →Inventory in, buyers scored and matched, reviewed proposals out, deals settled as retirements in the registry.
Explore →ESG compliance for Indian listed companies: one BRSR record per year, reviewed and reusable.
Explore →Investor onboarding and capital calls for Indian AIFs, with the fund register as the system of record.
Explore →See RHIZORA on your own data
Tell us about your programme and we’ll walk you through it.
Book a demo