Inside the CarbonVision dMRV stack

Strip away the language and a carbon credit is a database row: a quantity, a date, a method, an owner. What makes it worth money is not the row — anyone can write a row — but everything standing behind it. dMRV, digital measurement, reporting and verification, is the discipline of making that backing real: instrumenting the physical process so that every claimed number has a chain of custody back to a raw measurement no one can quietly edit [1].

We are building that layer as an independent platform, CarbonVision (carbonvision.io), rather than buying it, for a reason worth stating plainly: the evidence a certified removal needs cannot be reconstructed after the fact. You either recorded it at the time, in a form an auditor accepts, or you did not. This article is the architecture, and the reasoning behind each layer.

The four layers

Each layer exists to defeat a specific failure. The edge exists because human transcription is the weakest link in any measurement chain. The gateway exists because rural industrial sites lose connectivity, and data that only exists in transit is data you will lose. The ledger exists because a number an auditor cannot trace is a number they must discount. And the registry interface exists because methodologies change — the raw record must outlive the rules applied to it.

The edge: measure what changes, where it changes

Instruments sit on the production line itself: mass in and mass out, reactor temperature profile, feedstock moisture, run boundaries. The design principle is that a measurement should be taken as close as possible to the physical event, with as few human steps in between as we can manage. Every manual re-entry of a number is an opportunity for an error that is invisible afterwards — a typo and a fraud look identical in a spreadsheet.

Continuous data does something periodic sampling cannot: it establishes what normal looks like, so abnormal becomes visible. A temperature excursion in one run, a mass imbalance that should not exist, a drying fault at three in the morning — these are the events that quietly change the carbon content of a batch, and they are invisible to anyone reading a monthly summary.

The gateway: survive the real world

Pyrolysis happens where the biomass is: rural sites with unreliable connectivity, dust, vibration and power interruptions. So the gateway buffers locally and forwards when it can, rather than assuming a network. It timestamps and signs readings at the point of capture, so that a record's provenance travels with it, and it degrades gracefully: a site that loses its link keeps producing evidence, and reconciles when the link returns.

The ledger: the batch is the unit of truth

This is the central design decision, and it is a data-modelling one. Everything — sensor streams, laboratory certificates, feedstock origin, transport, lifecycle energy — attaches to a batch. Not to a month, not to a site, not to a project. The batch is the smallest unit that has a defensible carbon number, so it is the unit the entire system is scoped around, and it is what makes a single issued tonne traceable rather than merely plausible.

Records are append-only. A correction does not overwrite the original; it is a new record that supersedes it, with the reason attached. That sounds pedantic until you are the auditor: the difference between a system that shows you its corrections and one that shows you only its conclusions is the difference between evidence and assertion.

The reconciliation rule lives here too. When the sensor-derived carbon figure and the laboratory result disagree, the ledger carries the conservative value forward and logs the gap — the subject of a separate article. A rule that lives in software is applied to every batch; a rule that lives in a policy document is applied when someone remembers.

The registry interface: rules change, records do not

The final layer applies a registry methodology — Puro.earth's biochar methodology, and in time whatever the EU CRCF's delegated acts specify [2][3][4] — to the batch record, and produces the evidence pack an auditor works through. Keeping this layer separate is deliberate: methodologies are revised, permanence factors get updated, new frameworks arrive. When they do, we want to re-run the calculation over the same raw records, not go looking for data we never captured. The measurements are the asset; the methodology is a function applied to them.

What we are not claiming

This is an architecture and a set of commitments, not a boast about a running system. CarbonVision is being built alongside our first production capacity, and the honest status is that the design is what we are holding ourselves to as sites come online — including the integration with our highly specialised accredited laboratory partners, where permanence measured by R₀ petrography lands as structured data rather than as a PDF attached to an email. We would rather publish the standard we are building to and be held to it than describe a finished system that does not yet exist.

Figures 1 and 2 describe the architecture we are building to; they are design diagrams, not screenshots of a production system. Terms are defined in the glossary.