How we structure an R&D project for grant funding: OpenField
A written question, a baseline and a target, milestones a reviewer can run, and results reported against the target. Our farm-robot logbook shows each part.
A grant-backed R&D project is structured in four written parts: the technical question, the baseline and the target, milestones a reviewer can run, and results reported against the target. Funding programs pay to resolve a technical uncertainty, and a reviewer looks for these four parts. We write them before any work starts and report against them when it ends.
This article shows each part on OpenField, our logbook for agricultural robot fleets. It is the clearest example on our bench, because its question, measures and evidence rules are written down.
Status
Prototype
OpenField has no funding yet. It is a lab prototype tested on demo and simulated data, with no manufacturer integration. Field validation is planned for the 2027 growing season.
1. A written technical question
The question has to be narrow enough to answer and hard enough to need research. For OpenField it reads:
Can one logbook record what farm robots from different manufacturers did, where they failed and what the grower must report?
The uncertainty sits in the word “different”. Dealers who service robots from many brands have no common record. Each manufacturer’s software covers its own machines. A technician in a field often has weak signal, so the record has to work offline. And the grower’s paperwork, from food-safety audits to spray records and drone logs, has fixed formats that the record must fill.
2. Baseline and target
The baseline is the situation today: dealers keep no common record across brands. The target is field validation in the 2027 growing season, with Ontario dealers and growers who run robots from more than one manufacturer.
A target needs measures, fixed before the season starts. OpenField defines fifteen of them, K01 to K15, each computed from the logbook and never typed into a report by hand. A few of them:
| Measure | How it is computed |
|---|---|
| Hectares completed | Sum of pass areas, by block, task and ISO week |
| Passes on time | On-time cells ÷ expected cells; a week still running counts as neither |
| Interventions per hectare | Interventions logged by technicians ÷ deployed block area |
| Time to resolution by cause | Median and 90th percentile, per cause of intervention |
| Truck rolls and remote resolutions | Counts by response type |
| Connection availability | Live ÷ (live + stale) five-minute samples per machine |
| Cost per hectare, robot and hand-weeding baseline | Printed side by side, each term with its source |
Three rules make these numbers safe to put in front of a reviewer:
- Every number carries its source: machine telemetry, a manufacturer export, a farm-software import, a technician’s entry, or a benchmark.
- Missing inputs give a missing number. The measure reports “no data” and the report shows a gap. A missing rental cost shows as a blank in the report.
- A benchmark says so. When a hand-weeding baseline comes from the 85–120 hours per hectare benchmark instead of a measured control block, the report prints that sentence under the figure.
The logbook also declines four numbers: yield, weed-control efficacy, quality and ROI. The first three need a controlled field trial run by agronomists, so the logbook leaves them out. For ROI, the report prints both costs per hectare and leaves the division to the dealer or the lender.
3. Milestones a reviewer can run
A milestone should end in something a reviewer can run, open or verify. “Backend complete” fails that test. The OpenField build was split into ten work packages, each with the files it owns and its own tests:
| Package | Scope |
|---|---|
| WP0 Core | Schema, sign-in, tenancy, event API, batch ingest |
| WP1 Geo | Clients, fields, blocks |
| WP2 Fleet | Machines, data routes, connection health, store-and-forward |
| WP3 Jobs | Deployments, passes, the block × week grid |
| WP4 Ledger | Exceptions, interventions, rules, alerts |
| WP5 Measures | The KPI engine, labour entries, farm-software importers |
| WP6 Compliance | Applications, flights, maintenance, form exports |
| WP7 Evidence | Evidence pack, capture index, season report |
| WP8 Demo data | A simulated pilot season to test against |
| WP9 Front end | Operator screens and the two-tap phone entry |
The definition of done was written as three checks that anyone can repeat:
- A technician logs an intervention in two taps on a phone in airplane mode. After reconnecting, the ledger shows exactly one row, with its time to resolution.
- The season report for a demo client comes out with the block × week grid, interventions by cause, hours and hectares, costs with their sources and a compliance appendix. The CanadaGAP export refuses a pre-filled row until a person completes it.
- A machine connection with an edge queue loses zero events across a two-hour offline test.
Today the prototype exports CanadaGAP H1 forms, OMAFRA spray records, Transport Canada RPAS logs and AgExpert files, and it has more than 1,000 automated tests.
Simulation evidence, labelled as simulation
On 17 October 2026 we connected the logbook to ArduPilot’s software-in-the-loop simulator, and a lab script flew two simulated survey flights over a simulated field. The logbook only listened: it sent no command, mission or parameter. It derived two flight records from the autopilot’s own messages and opened a battery stop from ArduPilot’s failsafe text. The capture held 8,567 events, each with its raw MAVLink bytes. Replayed into a second, empty instance, it produced the identical event stream, with the same SHA-256 hash on both sides.
The evidence pack and a standalone verifier are public on GitHub . Its first limit is written at the top: this is a simulation, and the flight times and battery figures come from the simulator.
4. Results, failures included
The results are reported against the target after the 2027 season, including the experiments that fail. Two kinds of evidence stay separate in that report, because they prove different things:
- Integration evidence shows that the software received, normalized, kept and replayed a machine’s data. Every capture is sealed with a SHA-256 hash, and any later change fails verification. Each capture keeps its origin label: simulator, partner test site or physical vehicle.
- Field evidence shows labour, cost, uptime and interventions on real plots. A measured record needs a real plot size, an observer and a timestamp. Draft or planned records never produce a measured number.
A clean capture from a simulator proves the plumbing works. Hours saved on a farm come only from field evidence, and the report keeps the two apart.
What a partner brings
A field validation needs a field. We are looking for Ontario dealers and growers running robots from more than one manufacturer, for field validation in the 2027 season. In a joint project, the partner brings machines, fields and a season of real operations. INNOVA brings the software, the measurement design and the reporting. The models for that split are on Partnerships, and the R&D method behind it is on Innovation & R&D.
Checklist for your own project
Whatever the program, these questions decide whether the application reads as research or as a wish list:
- Can you state the technical question in one sentence, and say what makes it uncertain?
- Is the starting point measured, and is the target a number with a date?
- Does every milestone end in something a reviewer can run, open or verify?
- Does every reported number carry its source, and does a missing input show as a gap?
- Have you written down which results would count as a failure?
If the answer to the last one is “we have no failure case”, the project probably needs a sharper question. We help companies and researchers shape that question and build the software side of the work. The same rule runs through Workflow OS, where each projection is built to sit next to the measured actual once a pilot runs (see Client Onboarding, from process map to payback). To discuss a project of your own, write to us about R&D.
The same four parts carry into any program. For AI adoption in Ontario, the RAII guide sets out who qualifies and what the support pays. For technology R&D inside a product, see how an NRC IRAP project runs. For a new export market, CanExport SMEs has its own page. All of them sit side by side on funding for AI and software projects.
