Plant Breeding Trial Software: When One Broken Link Between Plot and Packet Costs a Season

Why a breeding program loses a season to a labelling error

Harvest, late in the season. A technician is bagging plots from a yield trial, and two envelopes go into the wrong tray because the plot tags got wet and the handwriting on the backup label is ambiguous. In February the advancement meeting looks at a line that performed unexpectedly well across three locations and moves it forward into a seed increase. Eighteen months later, when the increase is grown out and does not look like the line anyone expected, the program discovers that the identity broke at harvest and that the last unambiguous record of that material was a bag in a cold room.

Nobody loses a whole program to one mislabelled envelope. What they lose is trust in the data set, and once a research director stops trusting the means, decisions revert to the memory of the senior breeder. That is the real failure state in this category. A breeding program is a decade long chain of dependencies where each generation is derived from a specific physical seed lot, and if that chain has a soft link anywhere, everything downstream inherits the doubt.

The tooling around this is usually a mix: a nursery book in Excel, plot data collected on a handheld or a tablet, harvest weights in another spreadsheet, moisture readings on a slip of paper, marker data in a file from a genotyping service, and analysis run in R by whoever knows how. Agronomix AGROBASE, Phenome Networks and the Breeding Management System all exist and are all used seriously. The question is not whether they are good. It is whether their model of how material advances matches yours, because programs differ in the one respect that decides everything.

Problem 1: the seed lot is the atom, and most systems model the variety

A variety or a line is a concept. A seed lot is a physical thing with a location, a quantity, a harvest year, a parent lot and a germination test. Every planting consumes a lot. Every harvest creates one. Advancement decisions are decisions about lots, and inventory reality decides what is plantable next season regardless of what the data says should advance.

Systems that treat the genotype as the primary object and inventory as an attachment will let you advance a line you do not physically have enough seed of, which is discovered in the planting shed in March. What a build must include is the seed lot as the primary record with a parent link, so that a lot's ancestry is traversable back through every increase, cross and selection. Barcodes on packets, trays and bags, printed at the moment of creation, are not a convenience feature. They are the mechanism by which the chain stays unbroken, and a program that adopts barcode discipline at harvest and planting removes the single largest source of irrecoverable error.

Problem 2: pedigree and nursery structures are program specific in ways vendors flatten

How your program advances material is your intellectual property. Single seed descent, bulk advance, pedigree selection, doubled haploid production, backcross conversion of a trait into an elite background, marker assisted selection at a particular generation: each of these creates a different structure of records, and most programs run several simultaneously for different crops or objectives.

General purpose breeding packages support the common paths well. Where they push back is on the unusual one, which is often the one your program has built its advantage on. If your doubled haploid pipeline has a particular quality control step, or your backcross scheme tracks recurrent parent recovery in a specific way, you either adapt your program to the software or you keep a shadow spreadsheet. Most programs quietly do the second, and the shadow spreadsheet then becomes the real system while the official one holds a partial copy. That is the moment building becomes rational, because the cost of the custom system is now less than the cost of the divergence.

Problem 3: field layout, randomisation and spatial reality

Trials are designed: randomised complete blocks, alpha lattices, augmented designs with repeated checks, row and column arrangements chosen to handle field variation. The design has to be generated, converted into a planting order that a plot planter can actually follow, printed as labels and stakes, and then reconciled with what was actually planted, because a planter skips, a range gets shortened by a wet spot, and a fill plot goes in where a check was intended.

The build must hold designed layout and as planted layout as separate linked records, exactly as a mine holds designed and actual drill holes. Field maps must be printable in the orientation the technician walks, which sounds trivial and is the reason people abandon software in favour of paper. Handheld capture has to work with no connectivity for a full day in a nursery, must prevent a rater from entering a score against the wrong plot by scanning rather than typing, and should show the previous ratings for that plot so the rater can see continuity. Spatial adjustment at analysis time then has real coordinates to work with, rather than a nominal design that reality diverged from in week three.

Problem 4: phenotype data quality decides whether any of it is usable

Traits get scored by different raters on different days on scales that drift. Harvest weight needs moisture correction to a standard basis. Plots get damaged, flooded, grazed or lost, and a lost plot recorded as a zero is worse than a lost plot recorded as missing, because a zero enters the analysis as data.

What a build must include is a trait definition layer with explicit scales, units and permitted ranges, so that a score outside the range is rejected at the point of capture rather than found by a statistician in March. Missing and lost must be distinct from zero throughout. Rater identity should be recorded on every observation, which allows rater effects to be examined rather than assumed away. Harvest data should carry the raw weight, the moisture and the correction applied, not just the adjusted number, because a correction basis changes and you need to recompute rather than re measure. These are unglamorous requirements and they are the difference between a data set that supports a decade of genetic gain estimates and one that supports opinions.

Problem 5: genotype, phenotype and the analysis handoff

Marker data arrives from a genotyping service in its own format keyed to sample identifiers your laboratory assigned, and those identifiers have to reconcile to the seed lot that was sampled, which may have been a leaf punch from a specific plant in a specific plot. If that reconciliation is manual, it is the second most common place identity breaks after harvest.

The analysis itself will keep happening in R or in specialist mixed model software, and a build should not attempt to replace that. What it should do is make the inputs reproducible: a defined extraction of a trial set with its design, its as planted layout, its quality flags and its exclusions, exported in a form the analyst uses, with a record of exactly which extraction produced which set of estimates. Adopting the Breeding API specification for interchange is worth doing where you exchange data with public programs or collaborators, since it is the closest thing this field has to a common interface. Genomic selection then becomes tractable rather than aspirational, because the limiting factor for most programs is not the model, it is that phenotype and genotype records cannot be joined with confidence.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, this is the honest shape for breeding programs. A first release, meaning germplasm and seed lot inventory with parent links and barcoding, nursery and trial design generation with as planted reconciliation, offline handheld capture with trait validation, and season closeout into harvest lots, runs $60,000 to $140,000 and ships in 12 to 16 weeks. A full platform adding genotype linkage and sample tracking, reproducible analysis extraction, advancement decision workflow with the criteria recorded, seed increase and shipment planning including material transfer documentation, and multi location multi year querying runs $170,000 to $450,000 over 9 to 15 months.

What drives the price up specifically here: the number of crops, because a clonally propagated crop, a hybrid crop and a self pollinated crop have genuinely different structures and a system that handles all three is three systems. Doubled haploid or transformation pipelines, which add laboratory workflow. Seed shipment and regulatory documentation for international movement, including phytosanitary and material transfer agreements. Integration with automated phenotyping platforms or imagery. And migrating decades of legacy nursery books, which is often the largest single line item and is almost always underestimated, because historical data is inconsistent in ways only your longest serving breeder can resolve.

What keeps it down: start with inventory and one crop's nursery cycle, end to end, for one season. A program that can plant, score, harvest and close out one crop cleanly has proved the model, and the rest is extension rather than discovery.

Build versus buy, and when buying is the right call

Buy if you are a small public program or a young company running a few thousand plots a season on standard breeding schemes. The Breeding Management System is a serious option for public programs and comes with a community, and AGROBASE has a long track record in exactly this work. Phenome Networks is a reasonable choice where genotype and phenotype integration is the central need. In all three cases you will get further faster than with a custom build, and we would tell you so.

Build when two or more of these are true. Your program runs more than roughly 20,000 plots a season across several locations. Your advancement scheme or a key pipeline is proprietary and the package makes you keep a shadow spreadsheet for it. You are integrating an automated phenotyping platform, imagery or sensor data whose volume and structure a general package does not accommodate. Your commercial pipeline needs to connect breeding decisions to seed production planning, which is a different system in every package. Or your marker and phenotype data cannot currently be joined with confidence, which caps everything you could do with genomic selection regardless of how good your models are.

How to choose a developer for breeding software

Ask them to whiteboard the germplasm model before you sign anything. The right answer separates the genotype or line as a concept, the seed lot as a physical inventory item with a parent link, the plot as an observation unit, and the observation itself, and it can explain how a lot's ancestry is traversed. A developer who models a line with a quantity field has not understood that inventory and identity are the same problem here.

Ask how the handheld app behaves after eight hours with no connectivity, and how it stops a rater scoring the wrong plot. Scanning rather than typing, and showing previous ratings in context, are the two features that decide whether technicians adopt or quietly revert to paper.

Ask what they will not build. A competent partner will tell you that mixed model analysis stays in R or specialist software and that their job is reproducible extraction, not replacing your statistician. Anyone offering to rebuild the analysis engine is scoping a project you should not fund.

Ask who owns the code and the data, and get it in writing before kickoff. You should own the repository, the cloud accounts and the right to hire anyone else to continue the work. At Digital Heroes the code is yours from the first commit. A breeding data set outlives most software and most employment contracts, so exportability in an open format is a program requirement rather than a preference.