From a ranger's boot to a registry serial
A multi-tenant MRV platform for organisations generating verified environmental credits: field data captured offline in English or Swahili, corroborated by sensors and satellite, calculated against accredited methodologies, and issued to a registry.
Sector
- Climate tech
- Carbon credit MRV
Platform
- 16 screens
- 6 project types
Roles
- 6, from super admin
- to external auditor
Field ready
- Offline-first PWA
- English + Swahili
What does MRV actually mean?
Measurement, Reporting and Verification is the chain that turns an environmental intervention into a credit somebody will pay for. Break any link and the credit is worthless - which is why the software has to hold the whole chain, not the pretty end of it.
A credit is only as good as its evidence trail
A tonne of carbon becomes a tradable credit only if an auditor can follow it back to a measurement someone took in a specific place on a specific day. Sheldon Carbon carries that trail as one continuous object: field capture, sensor and satellite corroboration, a calculation run against an accredited methodology, and an issuance transaction against a registry.
Why is measuring carbon harder than reporting it?
Three constraints shape every serious MRV build. The data is collected where there is no network, by people who do not speak the language the software was written in; the numbers must be defensible years later; and the final act is a transaction against a third-party registry that must never happen twice.
| Step in the chain | Spreadsheets and email | In Sheldon Carbon |
|---|---|---|
| Field measurement | Paper forms typed up days later | Offline capture with GPS, photos and a sync queue |
| Changing a methodology | A new spreadsheet template circulated | Form templates updated without a redeploy |
| Quality assurance | A reviewer scanning a shared folder | A QA queue with approve and reject, and sync provenance |
| Sensor data | CSV exports emailed monthly | HMAC-verified webhooks into a hash-chained raw store |
| Detecting loss | Noticed on the next site visit | Satellite NDVI change detection raising an automated alert |
| Calculating credits | A spreadsheet nobody wants to audit | Parameterised calculation runs with uncertainty quantified |
| Issuing to a registry | A form submitted and hoped about | Two-phase commit ledger with idempotency and serial ranges |
What does it do, screen by screen?
The tour below follows the order the evidence moves: capture in the field, corroborate with sensors and satellite, calculate, report, then issue.
How did we build it?
What changes when the role changes?
Six roles, enforced rather than decorative: pick a persona and the sidebar itself changes, because the pages that role may not open are simply not there. Every screenshot below is the real navigation for that role. The chips list what the platform super admin can do, the first persona in the list.
- Create and manage tenants
- Set branded subdomains
- Apply per-tenant theming
- Manage users across the platform
- See no project data by default
What does any MRV or field-evidence platform need?
Six things separate an MRV platform that survives an audit from a dashboard that looks like one. They came out of building this one, and they apply to any system where evidence is collected in the field and money depends on it.
- Offline is the normal case, not the edge case. If field capture assumes a network, the data arrives late, retyped and unverifiable - or it does not arrive at all.
- Measurement schemas are data. Any platform serving more than one methodology has to change its forms without a release, or the science will outrun the software.
- Raw data must be immutable and provable. Hash-chaining and signed ingestion cost little up front and are the difference between evidence and assertion.
- Uncertainty is part of the number. A calculation that reports a single figure with no confidence interval will be challenged by the first serious verifier who reads it.
- External parties are users, not exports. Auditors and buyers need scoped read-only access inside the system; emailing them a PDF breaks the trail you spent the whole build protecting.
- Irreversible actions need two phases. Anything that writes to an outside ledger needs preparation, idempotency and a visible rollback path, or a network blip becomes a double issuance.
What does the interface look like, and why?
A forest-dark chrome against warm paper rather than the usual cold grey - the palette of the field, not the trading floor. Teal is reserved for action, and the six project types each carry their own hue so a portfolio map is readable without a legend.
Aa
Primary typeface
Fraunces
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
0 1 2 3 4 5 6 7 8 9 & ? ! £ $ €
34pxRegistry integrationH122pxSection headingH217pxCard headingH315pxLead copyLead13pxBody text and table cellsBody11pxCARBON & COMPLIANCEEyebrowCoordinates, idempotency keys, serial ranges and SHA hashes are all set in a monospaced face, because those are strings an auditor compares character by character. Instrument Sans, Fraunces and IBM Plex Mono are open-licence typefaces; the specimen above falls back to the nearest available face if they are not installed on your device.
What is a carbon MRV platform?
MRV stands for Measurement, Reporting and Verification. An MRV platform carries the whole chain that turns an environmental intervention into a credit somebody will buy: field measurement, monitoring evidence, calculation against an accredited methodology, verification by an external auditor, and issuance to a registry such as Verra or Gold Standard.
How long does it take to build an MRV platform?
A platform of this shape - six roles, multiple project types, offline field capture, IoT and satellite monitoring, a calculation engine and registry integration - is a substantial multi-phase programme rather than a single project. The biggest variables are how many methodologies must be supported and how many registries you integrate with, since each registry has its own API, states and reconciliation rules.
Why does the field app have to work offline?
Because the measurements happen where the network does not reach - mangrove plots, farms and remote monitoring sites. An offline-first app queues every capture locally with GPS and photographs and syncs when connectivity returns, so the data arrives intact and timestamped instead of being retyped from paper days later.
How do you prove field data was not altered?
By making the raw store append-only and verifiable. Sensor ingestion is authenticated with HMAC-signed webhooks and written into a hash-chained log, so any later edit breaks the chain. Combined with a read-only validator role and an explicit QA workflow, that gives an auditor an evidence trail rather than a report to take on trust.
How do you support more than one carbon registry?
By treating issuance as a ledger rather than an API call. Each transaction is prepared locally, sent with an idempotency key, and only committed once the registry confirms serials - so Verra, Gold Standard and the Clean Energy Regulator can sit behind the same workflow, and a failed or rolled-back issuance is visible instead of silent.
Related work
Have a field-evidence problem like this?
Tell us how your business actually works and we will tell you honestly what it takes to build. See more of our work or what we do.
Book a 15-minute call