Carbon Field, Part III — MRV is a data architecture, not a report
Why a monitoring report should be a query over field records, and the design choices that make it one
“Can we generate carbon credits from this?” Picture where that question is usually asked. A clean energy or land project has been going for a while. The equipment works, or the farmers are planting. The supply chain holds. The climate effect is real and the team can describe it. Is the project running? Yes. Is the impact genuine? Yes. But when someone asks what system would produce the evidence, the answer is often a shared drive, three survey exports and a spreadsheet that one person understands.
That is the moment teams discover that MRV (measurement, reporting and verification) is not a document you write at the end. It is the shape of the data from the first day. This article answers the second part of the late question, “What system would we need?”, for the people who build and run field data.
The report is the last step, not the system
A monitoring report looks like the product. It has tables, totals, maps and a signature. But according to the ICVCM Core Carbon Principles, reductions and removals are determined ex post and checked by a third party. According to Verra’s VM0042, each monitoring report replaces earlier estimates with measured data, and the change in practice has to be evidenced.
So the report is a claim about records. A verifier will pull a sample and ask to see where each number came from. If the report was assembled by hand from exports, the trail runs through someone’s laptop, and every copy is a place where the record and the report can drift apart.
The alternative is to design the field data so that the report is something you can produce again, from the same records, at any time, and get the same answer. Five choices make that possible.
The five parts of a yes
A yes to that question rests on five things a buyer or verifier will look for. This article is about one of them, monitoring systems. Carbon Field is the field-data tool we are building so that all five are produced on the farm, from the first visit:
- Baseline data: the baseline survey is a stage on every farmer’s record; the GPS point is averaged over several readings and held to a 10 m gate; photos are checked for blur and light; once a supervisor approves it, a correction has to be reopened, with a reason.
- Monitoring systems ← this article: monitoring rounds are numbered per farmer and cannot be reopened once sent; the surveyor’s route puts returned work first.
- Documentation: ID and consent documents are captured at registration; the consent signature is timestamped with who captured it; each project has its own forms.
- Verification readiness: a supervisor console with a review queue, a timeline per farmer, a map and exports (GeoJSON, KML); returning a record needs a written reason.
- Evidence trails: every record hangs off one farmer, is saved on the device first and queued until the server accepts it, and every review lands in an audit log that the app can add to but not change or delete.
Choice 1: one record per farmer
In a form-first tool, every visit is a row in a table for that form. The baseline lives in one table, consent in another, monitoring in a third, joined by a name typed three ways.
Make the farmer the record instead, and hang everything else from it. The verifier’s question “show me this farmer” then has one answer, and a duplicate becomes something you can check for at registration rather than discover at aggregation.
Choice 2: stages with states
A smallholder project visits the same farmer for years: baseline, consent, boundary mapping, implementation, then round after round of monitoring. Give each stage a small, shared set of states per farmer: not started, in progress, submitted, approved, rejected.
Get Stephen Oduor’s stories in your inbox
Join Medium for free to get updates from this writer.
That one vocabulary does a lot of work. It drives the surveyor’s list of who to visit, the supervisor’s review queue and the project’s funnel. It also answers a question verifiers and investors both ask: how many farmers are actually at each step, and how many are stuck?
Choice 3: what was sent stays sent
Here is the choice that matters most for ex-post quantification. Once a submission is sent from the field, it should not be edited. A monitoring round, in particular, should never reopen. Round three is its own record; it cannot quietly overwrite round two.
This feels rigid to the people doing the work. A surveyor sees a typo and wants to fix it. But a correction made in place destroys the very thing a verifier needs, which is the value as it was measured on the day. The fix is a new, dated entry with a reason, and a rule enforced in the database, not only in the app.
Choice 4: an audit log that only grows
Every record will be reviewed, and some will be returned, corrected, superseded and approved. Each of those is an event, and each needs four facts: who, what, when, and the value before and after.
Keep those events in a log that can be added to but not changed or deleted by any ordinary account. That is the record that lets you answer “why does this farmer’s area differ from last year?” with a dated decision and a name, instead of a shrug.
Review belongs in the same design. Every record should pass a person before it counts, and sending one back should need a written reason that travels with it.
Choice 5: exports built from the same records
A boundary in a verifier’s GIS tool and a boundary on the supervisor’s map should be the same boundary. So exports such as GeoJSON and KML should be generated from the live records, not from a copy someone cleaned up last month. When an export is a view over the record, it cannot disagree with the record.
Why this is hard, and why it is still worth it
According to a CGIAR review of smallholder participation in land-based carbon schemes, MRV that is rigorous, participatory and low-cost at the same time is still hard to achieve. None of the five choices above makes it cheap. They add work at the start: a registry to design, a duplicate problem to handle, offline identifiers to generate on the device, a review step that slows things down.
What they buy is a report that is a query, not a project. Ask the same question twice and you get the same answer, with a trail behind every number.
How Carbon Field applies it, and what it does not yet do
We are building Carbon Field, an offline-first field app and supervisor console for smallholder carbon projects, on these choices. In code and under test today: one record per farmer with five stages and per-stage states, submissions that cannot be edited once sent, monitoring rounds that cannot be reopened, an audit log that is insert-only, a review step where a return needs a reason, and GeoJSON and KML exports from the same records.
On the tablet, each monitoring round is its own submission, and a round that has been sent shows as locked.
In the console, the audit log shows who did what, when, and the values before and after.
A supervisor can approve, reject or flag a record, and every decision is kept beside it.
Back to the question
“Can we generate carbon credits from this?” usually turns into “what system would we need to show it?”. The short answer is a system where the report is the last, mechanical step over records that were designed for it from the first visit.
A test for your own project: could you delete last quarter’s monitoring report and produce it again from the raw field records, with the same numbers, by tomorrow? If not, which step in between lives only in someone’s head?
Carbon Field is still in development. We are looking for partners to take it into the field with us: project developers, NGOs, field teams and verifiers. We are also looking for a sponsor for satellite imagery, so surveyors can map parcels on real satellite maps, even offline. If that is you, send us a message. qsoftwares.org/carbon-field.html · info@qsoftwares.org · WhatsApp +254 101 609 998
