Agricultural Carbon Program Software: Building the Evidence Pack Before You Pay a Single Grower

The verifier asks a question your database was never built to answer

Two years into a program you have paid several thousand growers for cover crops and reduced tillage. A verifier sits down and asks a simple question about one field: show me that this practice change happened on this boundary in this year, show me what the practice was before, show me the evidence you relied on, and show me that this field is not also enrolled in another program claiming the same tonnes.

What most program operators can produce is an enrollment record, a grower attestation, some machine data in a format nobody has reconciled, a satellite derived tillage classification with no stated confidence, and a boundary that has changed twice because the grower rented a different piece of the quarter section. The practice probably did happen. The evidence that it happened is assembled by hand, per field, per year, and it takes weeks.

That gap has a direct financial consequence. Credits that cannot be evidenced are not issued, and grower payments that were made against unissued credits are not recoverable in practice, whatever the contract says. The program pays out on trust and gets paid on proof, and the software either closes that gap or it does not.

This is an evidence business wearing agronomy clothes

Program teams consistently underestimate this. The agronomy is the easy part. The hard parts are the ones that look like administration.

Field boundaries move. A grower enrolls 220 acres, then rents out 60 and picks up a different 80. The boundary you modelled against and the boundary the practice happened on are not the same polygon, and the reconciliation has to be recorded rather than resolved silently.

Practice evidence arrives at different strengths. A grower attestation, a planter as applied file, a retailer invoice for cover crop seed, and a remotely sensed classification are four different levels of confidence about the same fact. Storing them all as a single practice field throws away the only information the verifier cares about.

Protocol versions change under you. Methodologies at the registries are revised, and a project enrolled under one version may need to be handled differently from a cohort enrolled later. Baselines, additionality tests and uncertainty deductions are not constants, they are versioned rules with effective dates.

And double counting is a per field, per year question across programs you do not control. If a field is enrolled in your program and a grain buyer sustainability program, somebody has to be able to prove which claim belongs where.

Where Regrow Ag and Indigo Ag Carbon actually stop

Both are real and serious. Regrow Ag is a genuinely capable modelling and monitoring platform and is a reasonable component in a program stack. Indigo Ag runs its own carbon program with its own protocol, grower terms and buyer relationships. Neither is a bad choice for what they are.

They stop being the answer when your program is your own:

• If you originate the program, the protocol interpretation, additionality tests, evidence standards and payment terms are yours to defend, and running them inside somebody else program means their decisions are your exposure.
• Enrollment and grower relationship management sit with you, not with a modelling vendor. Your agronomists, your retailers, your contracts, your grower payments, your clawback terms.
• Modelling is one step in a chain, not the chain. Boundary reconciliation, evidence grading, sampling design, cohort accounting, verifier pack assembly and payment ledgers all sit outside the modelling platform and are usually where the manual work actually is.
• Buyer side chain of custody is your obligation. A food company buying the outcome wants a claim traceable to specific projects and vintages, and that traceability lives in your system.

The practical architecture we see working is a custom program system that owns enrollment, evidence, cohorts and payments, calling a modelling platform where modelling is required. Building your own biogeochemical model is not the recommendation here and rarely makes sense.

What a custom carbon program build has to include

• An enrollment and contract record per grower per field per crop year, with the protocol version, the payment terms, the clawback conditions and the exclusivity representation recorded at signature rather than assumed.
• Boundary management with versioning. Every boundary has an effective period, a source, and a reconciliation record when it changes. Silent boundary edits are the fastest way to lose a verification.
• Practice data intake from multiple sources with an explicit evidence grade on each: grower attestation, machine data file, input purchase record, agronomist field visit, remote sensing classification with a confidence value. The system should be able to say which evidence supported which claim and how strong it was.
• Baseline handling per protocol, including the historical practice window and how you handled fields with incomplete history, because that is the first thing a verifier probes.
• Model run orchestration as a tracked job: inputs snapshotted, model and version recorded, outputs stored immutably. A model result you cannot reproduce is not evidence.
• Soil sampling design and results where the protocol requires them, with the sampling plan, chain of custody and lab results tied back to the stratum and the project.
• Verifier evidence pack generation per project and vintage, assembled on demand rather than by a team over three weeks. This single feature is usually what turns a verification from a quarter long ordeal into a scheduled task.
• Cohort and vintage accounting: which fields, which years, which protocol version, which buffer pool contribution, what has been issued and what is pending.
• A grower payment ledger with the payment basis, the practice it paid for, and the clawback state, so that when a field drops out or fails evidence the financial consequence is visible rather than discovered at true up.
• Double counting controls: exclusivity attestations, cross program checks where data allows, and a field year uniqueness constraint that is enforced rather than hoped for.

What it costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this category prices as follows. A first release covering enrollment and contracts, versioned boundary management and structured practice intake with evidence grading runs $90,000 to $190,000 and ships in 14 to 20 weeks. A full platform adding baseline handling, model orchestration, sampling, verifier pack generation, cohort accounting and the payment ledger runs $240,000 to $550,000 phased across 8 to 14 months.

What pushes it up: the number of methodologies and protocol versions you operate under, since each is a distinct rule set with its own evidence standard; the variety of machine data formats you ingest, because agricultural equipment files are not a standard; and whether buyers require claim level chain of custody, which adds a whole reporting surface. What holds it down: pick one methodology and one geography for the first release. Programs that try to be protocol agnostic before their first verification usually build abstractions that turn out to be wrong.

When you should not build yet

Do not build if you are running a pilot under about 50 growers to find out whether the program economics work. A spreadsheet, a shared drive and one careful analyst will get you through a pilot, and building before your first verification means building against assumptions you have not tested.

Build once at least two of these are true. 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 simultaneously. You are paying growers before credits are issued and carry that exposure on your own balance sheet. Or a buyer has asked for claim level traceability and you improvised the answer.

How to choose a developer for carbon program software

Ask how they will version protocol rules. If the answer is configuration flags, ask what happens to a cohort enrolled under the prior version. Cohorts must remain evaluable under the rules in force when they enrolled, and that requirement shapes the whole data model.

Ask how they represent evidence strength. If practice data is a single field with a value, they are building an agronomy database and you need an evidence system.

Ask how a model run is reproduced two years later. The answer should involve snapshotted inputs, recorded model versions and immutable outputs. If a rerun today would produce a different number and nobody can explain why, your verification is already in trouble.

Ask who owns the code, the repository and the cloud accounts, in writing before kickoff. At Digital Heroes the client owns the code from the first commit. In a program where your evidence has to remain defensible for the full crediting period, you cannot afford a system you are not free to maintain or migrate.