Shrimp hatchery software: what a larval lab records

A shrimp larval lab does not have a season. It has runs. A tank is filled, stocked, taken through the stages, harvested to postlarvae, emptied, disinfected and filled again, and the next run starts before the paperwork from the last one is finished. Across a year the same twenty tanks hold dozens of separate populations, and the tank number tells you nothing about any of them.

That is why shrimp hatchery software is judged on a different axis than grow-out software. The question is not whether it can hold a pond for six months. It is whether the record survives a tank being reused twenty times, with the run rather than the tank as the thing that owns a history. A hatchery platform built that way can say where a batch of postlarvae came from. One built around tanks can only say where they were.

The unit of record is the run, not the tank

The population has to be a first-class object with its own identity, origin and history, and the tank has to be a placement it occupies for a period. Get that separation right and everything downstream works. Get it wrong and reuse destroys the record.

In practice the run is a batch: stocked with a count and an average weight, moved between units, split when density demands it, merged when it does not, closed when it is harvested or lost. Batches and placements keep the two apart, so a tank that has held forty populations still reports the one in it today, and each of the forty keeps its own dates, its own feed and its own outcome. A spreadsheet keyed on tank numbers cannot do this, which is the reason most labs end up maintaining a second notebook beside it.

The stages are the lab’s own, so the software has to let it define them

Maturation, nauplii, zoea, mysis, postlarvae. Every lab names them slightly differently, counts them differently and moves between them on its own criteria, so a platform shipping a fixed stage list will be wrong for most labs on the first day.

Cultivation phases are defined per operation rather than hardcoded, each with its own default feeding frequency, and stock moves between them explicitly rather than by a date rule. The same applies to the units. A maturation tank, a larval tank and a nursery raceway are all growing units, but each unit type carries its own defaults for volume and feeding, so a two hundred litre tank is not modelled with a pond’s assumptions. The lab describes its own process once and then works inside it, instead of translating its process into someone else’s vocabulary every time it enters a number.

Feeding is many small events, and the tanks are not all at the same stage

Larval feeding is not one delivery a day. It is several feedings, different products at different stages, live feed and dry feed running in parallel, across tanks that are at different points in the cycle on the same morning.

What the record has to hold is what was planned and what was actually given, per unit, per day, including the feedings that did not happen. The daily plan produces a ration for every stocked unit from the lab’s own feed table, the crew confirms what went in, and confirmed feedings draw down the stock of the item they used. Feed items are whatever the lab actually buys, so the stock figure is a consequence of the feeding record rather than a parallel count somebody maintains, and an item approaching its reorder threshold surfaces before the morning it runs out.

Survival is a curve across stages, not a number at postlarvae

A lab that learns its survival at harvest has learned it too late to act on. The number worth having is the one between stages: how many nauplii became zoea, how many zoea reached mysis, how many mysis made postlarvae, per run.

That figure only exists if every loss is entered against the run it belongs to on the day it happened rather than reconciled at the end. Where a tank holds more than one population the entry has to name which one lost the animals, and where one event covers several tanks it has to be apportioned across them rather than logged once against the lab. Both cases are ordinary in a larval lab, and both are where counts quietly stop being true. The water the run was held in belongs in the same place: readings bound to the unit rather than filed separately, so a bad stage transition can be read against the conditions it happened in.

A failed run is a record, not a deletion

Runs fail. A spawn that produces nothing, a tank that crashes in the first days. The instinct is to delete the row, and it is the wrong instinct, because the failures are the data that improves the next cycle.

Failed spawns are recorded as production alongside the successful ones, with the group, the date and the outcome. Over a season that becomes a comparison the lab could not otherwise make: which broodstock groups are performing, whether a protocol change moved anything, whether the bad weeks cluster around something. A record that keeps only the successes reports a survival rate the lab does not actually have, and the number will be discovered by a customer rather than by the lab.

The buyer of the postlarvae asks where they came from

A larval lab is a supplier, and its customers are farms that have been burned before. The question at the point of sale is where this batch came from and what happened to it, and the lab that answers it the same day gets asked again.

The answer is a chain: a batch of postlarvae, back through every split and transfer, to the run it started as, to the group or the delivery it came from. Because a split preserves the lineage link rather than creating unrelated new populations, that chain holds through the number of moves a larval cycle actually involves. Per-run reports exported to Excel or printed as PDF turn the request into a print job instead of a week in the archive, and the farms your postlarvae go to are keeping the other half of the same record.

How to test a larval lab demo

Give the vendor one tank and make them reuse it. Stock a run, take it through two of your own stages, split it into three tanks when density demands, record a mortality event that covers two of them, then close the run and start another in the same tank. Ask for survival between your stages afterwards, and for the origin of one postlarval batch. Those few minutes tell you more than any feature list, because reuse and splitting are exactly where hatchery records break. The four tests to run in a hatchery demo generalise the same idea, production control on the farm side covers what your customers are running, and a demo using your own stage names tells you the rest.