Sustainability reporting

On this page 11

The paperwork writes itself from the flights

Flight data, weather, soil and machine records combine into the input and water figures your buyers and schemes ask for.

CategoryOperate
Slugsustainability-dashboard
CadenceContinuous, with reporting periods you define
PayloadNo flight of its own. It consumes every other capability's output
Needs a visit firstNo

The problem

Reporting obligations keep growing while the underlying numbers still live in a spray diary, a fuel receipt and somebody's memory. Assembling a defensible figure for product use or water per hectare takes days, and the result is hard to audit because the evidence is scattered.

How it works

StepWhat happens
CollectEvery flight, prescription and as applied record is captured at the moment it happens
ReconcilePlanned against applied is reconciled per field, so the numbers reflect what went on, not what was ordered
AggregateField figures roll up to block, farm and enterprise level with the flight evidence still attached
ExportReports export in the formats schemes and buyers accept, with the source data one click away

What you get

  • Input use per hectare and per tonne
  • Water applied per irrigated hectare
  • Treated area versus total area
  • Audit trail per figure

What the dashboard measures

  • Product applied per hectare
  • Share of field treated
  • Water per irrigated hectare
  • Records with complete evidence

That last reading is the honest one. A report where 60% of the figures have evidence attached should say so, rather than presenting a confident total built on gaps.

Where it matters most

Cooperatives, organic farms, contractors, winter wheat.

Build it

There is nothing to fly and nothing to buy. This capability is a data model, a set of parsers, and a stubborn insistence that every number carries a link back to the record it came from.

The architecture that makes it work

Every figure is a derived value with a provenance chain, never a stored total.

figure  ──▶ aggregation  ──▶ records  ──▶ source
                                          (flight, prescription, as-applied
                                           log, meter reading, invoice)

Store the records. Derive the figures on read. The moment somebody stores a computed total, it drifts away from the evidence and the audit trail is decorative. This is the same principle the rest of this codebase runs on: the site renders treatedHectares from the TreatmentMap row rather than from a number typed into copy.

What has to be parsed

InputFormatEffort
Prescriptions issuedOur own ISOXML and shapefile outputFree, we wrote it
As applied logsISOXML TLG, or vendor APIsThe one real parser. See Prescriptions
WaterMeter readings, pump controller logs, manual entryLow
Fuel and energyInvoices, or the machine's own CAN dataManual entry is acceptable and honest
ProductThe spray diary the farm keeps by law anywayImport, do not re-key
WeatherDWD open data, freeLow
YieldWeighbridge tickets, combine logsLow

In-house software

StageWhat we runLicenceReplaces
Record storeThis repository's models, plus a per-farm event logMITfarm management software modules
ParsersISOXML TLG, shapefile, CSV importsGDAL MIT, own code
Unit handlingOne canonical unit per quantity, converted at the edgesown codea whole class of bugs
DerivationFigures computed on read from the record setown code
ExportCSV, XLSX and PDF with the evidence index attachedopen librariesscheme portals' own tooling
RetentionRecords kept for the scheme's audit period, immutablyown code

The requirements landscape, stated carefully

The reporting obligations that drive this change frequently and differ by country, scheme and buyer. As of writing, the ones that matter to a German arable customer include the Düngeverordnung documentation duties, the plant protection application records every holding must keep, CAP conditionality records, and whatever the buyer's own scheme asks for. Larger cooperatives are increasingly asked for figures that roll into their customers' corporate sustainability reporting.

Do not hard-code a scheme's template. Build the record model and the derivation engine, then treat each scheme as an export adapter. Templates change every year or two; the underlying record does not.

Cost efficiency

  • Zero hardware, zero flights, high margin. This is the capability that makes a scouting subscription stickier, because the reporting only works if the flights keep happening.
  • Import, do not re-key. The farm is already recording plant protection applications because the law requires it. Reading that file is worth more than any dashboard.
  • The evidence link is the differentiator. Anyone can total a column. Almost nobody can click a figure and land on the flight that produced it.
  • Sell it to the buyer, not just the farm. A cooperative or a processor needing comparable figures across dozens of holdings has a much stronger reason to pay than an individual grower does.