CDR Credits that survive verification.

Carbon removal credits on immutable chain-of-custody ledgers, with a calculation trail from source reading to ledger entry that a registry can verify.

A gas processing and capture facility — stacks, columns, and storage tanks under an overcast sky.

The problem

A credit is only worth what its evidence chain survives

Most carbon removal credits don't fail at generation. They fail at verification, when a third party asks how the number was derived, and the answer is a consulting deck.

[ 01 ] Failure mode 01

The accounting lives in a consulting deck

Methodology applied once, in a spreadsheet that ended with the engagement.

The methodology was applied once, by an outside team, in a spreadsheet that ended with the engagement. When the verifier asks how a tonne was derived, the trail ends at a cell with no formula history and an author who has rolled off the project.

[ 02 ] Failure mode 02

A ledger you can't audit isn't a ledger

Silently editable records are an assertion, not a chain of custody.

If credit records can be silently edited, re-keyed, restated, overwritten, the chain of custody is an assertion, not a record. A registry doesn't take assertions. It takes records whose every change is logged and attributable.

[ 03 ] Failure mode 03

Verification is a workflow, not a milestone

Treating verification as an event means rebuilding the chain each time.

The registry comes back with questions. The verifier wants the source measurement behind a derived value. Treating verification as a once-a-cycle event means rebuilding the evidence chain from scratch each time, usually under deadline.

The ledger is fed by systems you already run

[ 01 ] Measure

Measurement comes from sources you already operate

Calculation starts from measured data with provenance, not estimates.

Continuous monitors (Project Canary, Qube, LongPath), satellite (GHGSat, MethaneSAT), OGI, and SCADA historians (PI, CygNet) all normalize into the Warehouse's canonical model, so the credit calculation starts from measured data with provenance, not an estimate typed into a workbook.

consume: monitors, satellite, OGI, SCADA
[ 02 ] Contextualize

ERP context keeps the ledger tied to real assets

SAP and Maximo tie every credit to a specific facility and asset.

SAP and Maximo connections sync the asset registry, so every observation and every derived credit relates to a specific facility and a specific piece of equipment, the relationship a verifier traces first when testing whether a removal claim attaches to a real operation.

context: SAP, Maximo ← asset registry
[ 03 ] Verify

Third-party verification connects to Isometric and registries

Integrates with Isometric and registries; sign-off stays your process.

The verification leg integrates with Isometric, SensorUp's partner for verifying and registering carbon credits, and with registries. The integration carries the evidence; the multi-stage sign-off that moves a credit through review runs in your existing review process, against the same record.

verify: Isometric, registries

Every credit traces from source reading to ledger entry

[ 01 ] Catch

Every removal starts as a measurement, not an estimate

Monitors, satellite, OGI, and SCADA land as observations with provenance.

The removal is measured, not asserted. Continuous monitors, satellite, OGI, and SCADA readings land as observations in the Warehouse, each tied to the asset and the moment it was taken. The credit calculation starts from measured data with a source, not an estimate typed into a workbook.

catch: monitors, satellite, OGI, SCADA → Observations
[ 02 ] Prioritize

The methodology decides which tonnes count

Each measured tonne is checked against the methodology; only defensible removals advance.

The calculation engine derives each tonne from the observations, then applies the methodology you verify to, tonne by tonne. The removals that hold advance toward issuance and a verification buffer is held back, so what a registry would challenge surfaces before a credit is minted, not after.

prioritize: measured tonne → methodology → creditable | buffer
[ 03 ] Resolve

The credit resolves to a ledger a registry will accept

Immutable chain-of-custody ledgers, with Isometric and registry verification.

Each credit resolves onto an immutable chain-of-custody ledger: every entry, state change, and verification record logged and attributable. The Isometric and registry integration carries the evidence a verifier works against. When the registry asks for a credit's history, the answer is the ledger itself, not a narrative assembled around it.

resolve: Ledger + Isometric / registries

CDR Credits is composed from the same blocks

The credit ledger is assembled in Studio from shared blocks, run by Autopilot, and anchored to the Warehouse record beneath it. The same measured-to-defensible discipline backs the corporate GHG inventory, and the blocks compose every solution.

[ 01 ] Studio COMPOSE
  • Events
  • Work
  • Calculations
  • Compliance
  • Scenarios
  • Metrics
  • Reports
[ 02 ] Autopilot AUTOMATE
  • Agents
  • Cora
  • Solution Builder
  • Workflows
[ 03 ] Warehouse FOUNDATION
  • Assets
  • Integrations
  • Datasets
  • Relationships
  • Reference Library
  • Ledgers
  • Approvals
CDR Credits draws Calculations from Studio, the sign-off Workflows from Autopilot, and Datasets, Integrations, and Ledgers from the Warehouse. The blocks are shared across every solution; only the composition changes.

Trace a carbon-removal credit back to the measurement that earned it

Removal claims reconcile against measured data and resolve to credits whose provenance survives the export, the number a verifier accepts.

app.sensorup.com/removal
SensorUp product screen: the calculation graph behind a removal figure
A frame from the product interface.
$schedule --with engineer --bring your-verifier

Talk to an engineer

Bring the methodology you verify against. We'll walk the evidence chain, source reading to calculation to ledger entry to verification record, against your actual stack.

SecurityTrust ↗