Case study, climate and certification technology
A global testing, inspection and certification authority verified greenhouse-gas reduction projects and issued carbon credits through spreadsheets, emailed PDFs and manual review, with no separation of duties, no tamper-evidence, and no way for a third party to prove a credit was genuine.
Sealed at issuanceRS256, in a managed vault
0
capability domains in the function tier
0
architecture zones, split by responsibility
0
decisions behind what it can be trusted to do
0
signing keys held in application code
An international testing, inspection and certification body that validates greenhouse-gas reduction projects and issues the carbon credits those projects earn.
No tamper-evidence, no separation of duties, and no way for a counterparty to check a credit short of calling the authority.
A dual-workflow registry: the customer ingests, an auditor approves through a defined lifecycle, and issuance seals the credit.
Every credit signed in a managed key vault, with a public, hash-addressable opinion any third party can open without an account.
The client
When they certify that a project removed a ton of CO2e, buyers, regulators and registries treat it as fact.
The client is an international testing, inspection and certification body that validates greenhouse-gas emission-reduction projects and issues the carbon credits those projects earn. Their name carries the weight.
But the process behind the signature was manual. Project documents arrived by email. Emission calculations lived in spreadsheets. Credits were recorded in disconnected files, and the verification opinion that vouched for a credit was a PDF, reproducible by anyone with the template.
The authority of the brand rested on evidence the system itself could not defend.
The challenge
Carbon credits are financial instruments. A buyer retires them against emissions targets; an auditor may challenge them years later.
The moment a credit cannot be traced back to a validated project and an accountable reviewer, its value is in question. Three gaps made every issued credit a latent liability.
A credit record was a row in a document. Nothing proved it had not been altered after issuance, and nothing let an outside party confirm it independently.
The same manual process captured a project and blessed its credits. There was no system-enforced boundary between the person entering data and the auditor approving it.
A counterparty who received a credit had no way, short of contacting the authority, to check that the verification opinion was authentic and unchanged.
A certification body's product is trust. If the platform that issues its credits cannot prove they are genuine, the brand is underwriting risk it cannot see.
The mandate
Let customers register projects, sites and credits as validated data objects, with documents attached, emission factors captured and provenance recorded, rather than as free-form files.
Route every project and credit through an auditor who moves it along a defined lifecycle, so approval is a deliberate, attributable act and never an assumption.
Seal each issued credit and transaction with a cryptographic signature that makes tampering detectable and issuance non-repudiable.
Publish a read-only, hash-addressable verification opinion for every credit, so any third party can confirm authenticity without an account and without calling the authority.
The solution
Nothing becomes a live credit by default. A credit is issued only after its parent project is approved.
The platform splits the world into two mirrored workflows. On the customer side, an organisation ingests projects with their emission-reduction methods and supporting documents, the sites those projects run on, and the carbon credits they generate. On the auditor side, a reviewer sees the same records and walks them through a controlled lifecycle.
At the moment of issuance the platform seals the credit: a cryptographic signature is applied, a PDF receipt is generated, and a public verification opinion, addressable by a content hash, is produced. A separate machine-to-machine tier lets partner systems submit projects, sites and sales programmatically, and receive signed callbacks when an audit completes.
The audit lifecycle
What each role sees
A registry of projects, sites and credits filtered to their tenant. A project carries its methods, emission factors, validity dates and documents, and a credit is computed from its typology and emission factor.
Attachments and transaction certificates upload alongside the record, and everything submits for audit as one structured object.
The same records in a validation queue, with a read-only detail view and every attachment downloadable as a bundle.
The reviewer moves the record along its lifecycle: start, approve, reject, or send back for revision with notes. Approval is the act that unlocks credit issuance.
Carbon-credit sales and the customer registry. Sales consume credits oldest first, decrementing available balances.
Each transaction is sealed and given its own verification opinion, so a retired credit is as provable as an issued one.
Credits map to recognised methodologies
Architecture
A suite of independently deployable serverless functions, each owning one capability, behind a role-aware API surface.
Human users reach the platform through a single-page application authenticated against a managed identity provider; partner systems reach a parallel machine-to-machine surface authenticated per tenant. State lives in a document database, evidence in object storage, and signing keys never leave a managed vault.
A request enters through the web app or the machine-to-machine tier, is authenticated and checked against the user's role and tenant, and is handled by the function that owns that capability. Writes persist to the document store and object storage. An audit decision drops a message on a queue, which a separate function picks up to send notification emails and fire partner webhooks, so the reviewer's click and the downstream side-effects are decoupled.
Seven zones, seven responsibilities
Capabilities at a glance
The function tier is not one monolith. It is a set of capability-scoped services, each split between a human surface and, where partners integrate, a machine-to-machine one.
Inside the build
The private key that seals a credit never enters application memory. Every signature is produced by a managed key vault performing RS256; the service holds only a reference.
A leaked application server cannot forge a credit, and issuance is non-repudiable by design: the authority can always prove a credit was sealed by its own key.
Data entry and approval are different functions with different permissions, not two states of one screen.
The maker and the checker act through distinct endpoints governed by distinct roles, so separation of duties is enforced by the architecture rather than by policy or good behaviour.
Before a record is signed, its JSON is serialized with sorted keys, so the same data always produces the same bytes and therefore the same verifiable signature, whichever service or language reads it.
Third parties can re-derive and check the signature independently, which is the whole point of a public verification opinion.
A credit's proof is not behind a login. Each verification opinion is a read-only page addressed by a SHA-256 hash of its evidence.
Anyone holding the link can confirm the credit is authentic and unaltered without an account and without contacting the authority, which turns trust from a phone call into a URL.
When an auditor approves or rejects a project, the platform does not send emails and call partner webhooks inline. It drops a message on a queue and a separate function delivers the notifications.
The reviewer's action stays fast and reliable even when a downstream partner endpoint is slow or down, and delivery can be retried without re-running the decision.
Every request is checked against a typed schema before it reaches business logic: dates must be ISO-8601, emails and VAT numbers must be well formed, and conditional rules fire where the data demands them. Certificate fields, for instance, are required only when a project is marked validated.
Bad data is turned away at the edge, never discovered later inside a signed record.
End to end
One credit, traced from registration to independent verification. Every step below is a capability in the platform, not a manual handoff.
Its emission-reduction methods, emission factors and supporting documents. It enters the audit queue as inserted.
Submitted, then started, then approved, with a revision loop back to the customer when data needs correcting. Only a validated project can issue credits.
The platform computes it from the project's typology and emission factor.
Its record is serialized deterministically, signed in the managed key vault with RS256, and a PDF receipt is rendered server-side.
Read-only, and addressed by a SHA-256 hash of its evidence.
The balance is decremented and the transaction is sealed with its own verification opinion.
No account, and no call to the authority.
Every credit now carries its own proof. A buyer does not have to trust the spreadsheet. They can verify the signature.
Security and reliability
Because the product is a credit others will rely on, the controls are not add-ons. They are the same mechanisms that make a credit provable.
Outcomes
The platform's value is structural: trust, traceability and separation of duties that the previous manual process could not provide.
Delivered, against what is still a target
The capabilities below are delivered and verifiable in the codebase. The business metrics are the targets the platform is built to move, and they are published here as targets, to be measured once operational data is available.
Every issued credit cryptographically signed with RS256Capability in production code
Public, hash-addressable verification opinionsSHA-256 addressable
System-enforced maker and checker audit workflowSeparate ingestion and audit endpoints
Signing keys never exposed to application codeAll signing in a managed vault
Machine-to-machine partner integration tierPer-tenant authenticated endpoints
Reduction in credit-verification turnaround timeTo be measured post go-live
Elimination of unverifiable or disputed creditsTo be measured post go-live
Partner systems onboarded through the M2M tierTo be confirmed with the client
Beyond the measurable, and already true of the delivered system
An unverifiable manual process became a system-enforced maker and checker workflow.
Credit authenticity is checkable by any third party, without contacting the issuer.
Issuance is a non-repudiable, tamper-evident act. A credit can be defended after the fact.
Disconnected spreadsheets and PDFs consolidated into one multi-tenant registry.
What comes next
Extend the signed-credential model with decentralized identifiers, so credits are verifiable against a public trust root rather than only the authority's own site.
Map issued credits to external carbon-standard registries for cross-registry recognition and retirement.
Grow the embedded dashboards into portfolio-level KPIs: issuance, retirement, audit throughput, and reduction impact by programme and geography.
Flag anomalous emission calculations or documentation gaps for auditors before manual review, shortening the audit lifecycle.
What the repository already carries
Beyond the running platform, the codebase carries the scaffolding of a maintained delivery pipeline: a frontend unit-test setup with a coverage configuration, a CI pipeline definition, and a container build for the backend. These show how the system is built and shipped. Specific coverage levels or deployment cadence are not asserted here.
The stack, end to end
If the answer is no, the proof lives in your process rather than in your product. We can walk your issuance path end to end in a single session and show you where the evidence stops.