Agricultural Carbon Program Software Problems: The 7 That Cost You Credits, and How to Avoid Them

Why do carbon program builds try to be protocol agnostic on day one?

It feels responsible. You intend to run more than one methodology eventually, so the team builds an abstraction layer that can express any protocol, and six months later the abstraction is wrong in ways that are expensive to unwind. This is the biggest scope failure in the category, and it is specific to carbon because protocols are not variations on a theme. Baselines, additionality tests, uncertainty deductions, sampling requirements and permanence obligations differ in kind, not degree, and they are revised over time with effective dates.

The second version of the same mistake is building your own biogeochemical model. It is almost never where program risk lives. Modelling is one step in a chain. The manual work in nearly every program we have seen is boundary reconciliation, evidence assembly, sampling logistics, cohort accounting and verifier pack preparation, none of which a model touches.

The fix is to pick one methodology and one geography for the first release, and to build the program system that owns enrollment, evidence, boundaries, cohorts and payments while calling an existing modelling platform for the modelling step. Add the second methodology only after the first has been through a verification, because that is the point at which you know what the abstraction actually needs to express. Programs that generalise before their first verification build for assumptions they have never tested against a verifier.

What goes wrong with field boundaries and enrollment data?

Boundaries move, and they move for ordinary commercial reasons. A grower enrolls 220 acres, rents 60 of them out and picks up a different 80 the following season. The polygon you modelled against and the polygon the practice happened on are no longer the same shape. If your system holds one current boundary per field and edits it in place, the link between claim and evidence is broken and there is no record that it ever existed.

The migration version of this problem is worse. Most programs start in spreadsheets, where a field is a row with an acreage, a grower name and a shapefile somebody emailed. Moving that into a real system means reconciling names that are not consistent, boundaries drawn by three different agronomists at three levels of precision, and enrollment years recorded as text. Whatever the spreadsheet says the acreage was is not necessarily what the polygon computes, and both numbers have been used in payments.

The fix is versioning as a first principle. Every boundary carries an effective period, a source and a recorded reconciliation when it changes. Nothing is edited in place. Acreage is computed from geometry and the discrepancy against the enrolled figure is stored rather than resolved silently, because that discrepancy is exactly what a verifier will find. At migration, load the spreadsheet history as source records with their own provenance instead of overwriting them into a clean state that hides how you got here.

Why do equipment data and modelling integrations break after launch?

Agricultural machine data is not a standard. Files arrive from different brands of display, in formats that vary by firmware, with headers that change when a dealer updates a monitor. A planter as applied file from one operation looks nothing like the same event from a neighbour's kit. Programs that build an ingest pipeline against three growers' files in a pilot discover in year two that adding two hundred growers means adding a long tail of formats nobody anticipated.

The other integrations fail more quietly. A modelling platform such as Regrow Ag returns results against inputs you supplied, and if the input snapshot was not stored, a rerun a year later against a revised model version produces a different number that nobody can explain. Remote sensing classifications arrive with confidence values that get discarded on ingest. Lab results for soil sampling come back keyed to a sample identifier that does not match the stratum it was drawn from because the chain of custody form was filled in by hand.

The fix is to treat every external input as evidence with provenance rather than as data. Store the raw file alongside the parsed result, so a parsing bug is recoverable. Snapshot every input to a model run, record the model and version, and store the output immutably, because a model result you cannot reproduce is not evidence. Carry the confidence value from remote sensing through rather than flattening it to a yes or no. And key lab results to the stratum and project at the point the sample is taken, not when the results arrive.

What happens when evidence grading and double counting are not covered?

These are the two gaps that turn a working program into a failed verification. Evidence grading first. A grower attestation, a planter as applied file, a retailer invoice for cover crop seed and a remotely sensed tillage classification are four different levels of confidence about the same fact. Stored as one practice field with a value, you have thrown away the only information the verifier is actually assessing. When they ask what supported this claim, the honest answer becomes a search through email.

Double counting is the other. If a field is enrolled in your program and simultaneously in a grain buyer's sustainability program, someone has to be able to prove which claim belongs where. Exclusivity is usually handled as a checkbox in an enrollment form, which is a representation rather than a control.

The fix on evidence is to model each item separately with an explicit strength, a source and a date, so a claim can show its supporting evidence stack rather than a single value. On double counting, enforce field year uniqueness inside your own program as a database constraint rather than a business rule people can override, capture exclusivity as a contract term with the grower's signature attached rather than a tick, and run cross checks against any registry or partner data you can legitimately access. The residual risk from programs you have no visibility into is a governance and contractual problem, and you should say so plainly to buyers rather than implying a control you do not have.

Should you build custom or configure what you already own?

Configure, or rather stay on what you have, if you are running a pilot under roughly fifty growers to find out whether the program economics work at all. A spreadsheet, a shared drive and one careful analyst will carry a pilot, and building before your first verification means encoding assumptions a verifier has never tested. We tell people this on the first call more often than they expect.

Use Regrow Ag for modelling and monitoring rather than building it. It is a genuinely capable platform and a reasonable component in a program stack. If you do not originate your own program at all, and your growers can simply enroll in a program somebody else runs, Indigo Ag Carbon operates one with its own protocol, terms and buyer relationships, and joining is a legitimate answer for organisations that do not want to own the protocol risk.

Build once at least two of these hold. You have completed a verification and know exactly which evidence was challenged. You are past a few hundred growers, which is roughly where per field manual assembly stops being possible. You operate more than one methodology or more than one crop year cohort at once. You are paying growers before credits are issued and carrying that exposure yourself. Or a buyer has asked for claim level traceability and you improvised the answer.

How do hidden costs get into the quote?

The number of methodologies and protocol versions is the first. Each is a distinct rule set with its own evidence standard, its own baseline treatment and its own uncertainty handling, and a quote written for one and delivered for two is not the same project. Count them, including versions you will still be carrying for cohorts already enrolled.

The second is machine data format variety, which is invisible until scale. Price ingest by the number of distinct file formats you must accept, not by the number of growers, and accept that the long tail will keep arriving for years.

The third is buyer side chain of custody. If a food or fibre buyer wants a claim traceable to specific projects and vintages, that is a reporting surface with its own data model and its own assurance expectations. It is frequently mentioned late in a sales conversation and priced as an afterthought.

The fourth is soil sampling logistics, if your protocol requires it. Sampling design, stratification, chain of custody and lab result reconciliation is a workstream, and it involves field operations rather than software alone. The fifth, and the one that most often extends timelines, is agreeing your own evidence standard internally. Programs discover during discovery that the agronomy team, the commercial team and the person who will face the verifier hold three different views of what counts as proof.

What separates a build that works from one that fails here?

The working build treats the verifier as the primary user. Not the agronomist, not the grower relationship manager, the verifier. If the system can assemble an evidence pack for a named project and vintage on demand, everything else in the program tends to be right, because that single capability requires versioned boundaries, graded evidence, reproducible model runs and clean cohort accounting to already exist.

The second difference is a payment ledger tied to the practice it paid for and to the clawback state. Programs that pay from a spreadsheet and account for credits somewhere else cannot see their own exposure. When a field drops out or fails evidence, the financial consequence should appear immediately rather than at true up.

The third is protocol rules held as versioned data with effective dates rather than as configuration flags. Cohorts must remain evaluable under the rules in force when they enrolled. Retrofitting version awareness after two cohorts have been paid is a rebuild, not an enhancement, so ask any prospective developer about it before anything else.

The fourth is ownership settled in writing before kickoff: the repository, the cloud accounts and the unrestricted right to hire another firm. At Digital Heroes the client owns the code from the first commit. Your evidence has to stay defensible across a full crediting period measured in years, and being unable to maintain or migrate the system that holds it is a direct risk to credits you have already paid growers for.