Case study: digital MRV for biochar carbon credits

Return on investment

1hour per day taking readings savedReporting ready outputs logged automatically.

4hour per week compiling reports savedOutputs match required format.

£10kper year saved on off the shelf dMRV systemsAvailable alternatives are expensive.

Cashflow positve

Reliable compliant data means more regular carbon credit issuance, bringing cash into the business more frequently with less delay.

Background

Industrial pyrolysis plants, streaming live telemetry

Our client is a biochar carbon project developer operating industrial pyrolysis plants, converting biomass feedstock such as oil palm trunk and empty fruit bunches into biochar. Each plant streams live PLC data across roughly 155 sensor registers: temperatures, motor currents and speeds, gas and pressure, flow and alarms. Every tonne of biochar they sell as carbon removal has to be proven. Not described, proven, with evidence a registry or verifier will accept.

Onnu engineer holding raw feedstock in one hand and finished biochar in the other

The challenge

No structured way to prove a run met MRV requirements

Machine telemetry and business/compliance data lived apart, with no structured way to prove a production run met MRV (Monitoring, Reporting, Verification) requirements.

01

No single connected record

Nothing connected what feedstock went into a run, how the reactor actually performed, and whether that run qualified for compliance or carbon claims.

02

155 registers nobody could read

Raw PLC alarm codes and sensor tags were machine identifiers, not language. Turning a run’s telemetry into something a compliance report could use meant someone who knew the plant sitting down with the logs.

03

QA that wasn't logged

Operator checks during a run were ad hoc rather than recorded, so the quality of the evidence depended on who was on shift.

04

A wrong figure reaches the registry

With business data siloed from run data, a wrong number could travel all the way into an issued claim before anyone noticed. In carbon removal that is not a correction, it is a reversal, and it costs trust as well as credits.

Mainspring solution

AI checks the evidence. The claim rests on what survives.

Every run audited on arrivalAI reads each completed run against the project’s own history: does the mass balance close, does residence time hold through the main phase, is there a telemetry gap where evidence should be. The run arrives with a verdict and a list of what to look at, rather than waiting for someone to find the problem later.
Checked against the methodology it is claimed underEach run is tested against the thresholds the relevant methodology sets for temperature, residence time and measurement, and the platform states which criteria are met, which are marginal and which fail, with the clause behind each verdict.
Drift caught across runs, not just within oneA thermocouple reading consistently low, moisture creeping up, a sensor that quietly stopped updating. Invisible in a single run and fatal across a batch of claims, these are surfaced before they reach the registry. The team has already corrected figures this way, including an energy metric, before they travelled onward.

See it in actionPick a screen, use the arrows, or tap the cards behind

01Every run, already a record02Three levels, one traceable claim03Telemetry read, and checked04Data out, on your terms

01 / 04

02 / 04

03 / 04

04 / 04

01

Every run, already a record

Each production run is captured as it happens with its feedstock type, input and output mass, moisture, duration and timestamps, ready to export over any date range. Nothing is reassembled from logs after the fact.

Captured liveExport any rangeRegistry format

platform.example.com/mrv/runs

Thirty-five runs held as records, not as logs waiting to be interpreted.

02

Three levels, one traceable claim

Machine configuration, production run data and minute-level telemetry are held as one linked record per run, so every figure in a claim traces back to the reading it came from. A verifier’s questions are answered from the record rather than reconstructed by an engineer.

Config, run, telemetryLinked per runTraceable

platform.example.com/mrv/runs/detail

Configuration, mass balance and energy use for one run, in one place.

03

Telemetry read, and checked

Every sensor tag is decoded into a named, scaled reading, so 723 records of thermocouples, oxygen, pressure, auger speed and residence time become something a report can quote. AI reads the trace against the run’s own history, separates a genuine process excursion from a sensor dropout, and flags each record that does not hold up.

Tags decodedAnomalies flaggedOne-minute resolution

platform.example.com/mrv/telemetry

Twelve hours of two-channel telemetry, each record carrying its own anomaly flag.

04

Data out, on your terms

Keys are issued per machine, separating the plant’s own ingestion from the customer-facing API. Registries and dMRV providers pull the runs they are entitled to over a standard endpoint, without the developer paying for a third-party platform to sit in between.

Keys per machineScoped accessOpen API

platform.example.com/settings/api-keys

Each customer key returns only the runs from the machine it was issued against.

The outcome

Claims that survive scrutiny, because they were checked first

Machine telemetry, compliance data and feedstock data sit in one connected system, and every run is checked before it becomes a claim:

A run's compliance case is generated, not reassembled. The evidence exists the moment the run ends, in the format a registry expects.

QA is systematic rather than personal. Hourly operator checks are logged against the run, so the strength of the record no longer depends on who was on shift.

Discrepancies are caught before issuance, not after. Each run is checked against its own history and the methodology behind it, and the team has corrected errors this way, including an energy metric, before they travelled onward.

Credits issue more often, and hold. Verifier-ready evidence that has already been checked means more regular issuance, and far less risk of a reversal later.

Work with us