Shrimp export traceability software after the 2028 FDA delay

In November 2025, Congress directed the FDA not to enforce the Food Traceability Rule before 20 July 2028 — a thirty-month slip from the original date of 20 January 2026. If you ship shrimp into the United States, that reads like a reprieve. It is not one, and shrimp export traceability software is still the thing to start building this year rather than in 2027.

The reason is not regulatory brinkmanship. It is that the rule asks for a kind of data that most aquaculture supply chains have never captured, at the one moment nobody is holding a laptop: harvest. Thirty months is roughly how long it takes to change that, and we know because we have done it.

What the rule actually asks of a shrimp chain

Crustaceans are on the FDA's Food Traceability List, and the entry is deliberately broad. It covers all crustacean species — shrimp, crab, lobster, crayfish — in fresh, frozen and previously frozen forms. There is no carve-out for farmed versus wild. If it is shrimp and it is going to a US buyer, it is in scope.

What the rule requires is not a certificate. It requires records: Key Data Elements captured at Critical Tracking Events. There are seven of those events — harvesting, cooling, initial packing, first land-based receiving, shipping, receiving, and transformation — and the data required differs at each one.

Note the fourth. First land-based receiving exists in the list specifically because seafood arrives from water rather than from a field, and the FDA wanted a defined point where a lot enters the land-based chain and becomes traceable. For a shrimp exporter, that is usually the moment product reaches the processing plant — and it is the point where most existing systems begin. The rule expects you to have records from two events earlier.

Why thirty months is less runway than it sounds

The software is the easy part. A platform that stores lot codes, links them to ponds, and produces an electronic sortable spreadsheet on demand is a few months of work for a competent team.

The hard part is that a traceability record is only as good as the moment it is created. For Indian shrimp, that moment happens at a pond bank, often before dawn, in the hands of a farmer or a field agent who is not a software user, frequently with no signal. If the pond identity is not attached to the harvest right there, no amount of downstream engineering recovers it. You can reconstruct paperwork. You cannot reconstruct which pond a container came from.

We built Aquapulse, an aquaculture platform that runs pond-to-port across Odisha, Andhra Pradesh and West Bengal, covering more than 6,000 registered farmers, 150 villages and 8,000 acres of ponds. The platform took months. Getting reliable capture at the pond took considerably longer, and it was not a technical problem. It was a question of whether a field agent could complete the record faster than the old way of doing nothing, on the device already in their pocket, with the network down.

That is the work thirty months buys you. Teams that treat July 2028 as a software deadline will start in 2027 and discover in 2028 that they have a system nobody at the pond uses.

What shrimp export traceability software has to record

Translating the seven events into an aquaculture chain is the design exercise that matters. Roughly:

Critical Tracking Event	What it means in a shrimp chain
Harvesting	Pond identity, farmer, date, and the traceability lot this harvest becomes
Cooling	Time and location product first came under temperature control
Initial packing	Where a raw agricultural commodity becomes a packed lot with a code
First land-based receiving	Entry into the land chain, typically the processing plant
Shipping	Lot, quantity, origin and destination for each movement
Receiving	The mirror record at the next holder in the chain
Transformation	Input lots to output lots when product is peeled, blended or repacked

Transformation is where most designs quietly break. A processing run takes many input lots and produces output lots that no longer map one-to-one to a pond. If the system cannot express a many-to-many relationship between input and output lots, it will either lose the link or force an operator to invent one. Both fail the same way under a recall.

Work it through. A processing run takes delivery from six ponds on a Tuesday, grades the combined volume into three size counts, and packs each count into cartons that ship to two different buyers. There is no one-to-one relationship anywhere in that sentence. Every output carton traces back to all six ponds, and every pond appears in all three size counts. A schema that stores a single parent lot per carton cannot represent it, so somebody picks the largest contributor and moves on. That decision is invisible until the day it matters.

The fix is unglamorous: a join table between input lots and output lots, with quantities, written at the moment of the run rather than reconstructed from production reports afterwards. It is the single most important table in the system and it is usually the one added last.

Design for the recall, not the audit

An audit is scheduled and someone prepares for it. A recall is not. The question that matters is how long it takes to answer "which ponds contributed to this container, and what else did those ponds ship" — and to answer it while a buyer is holding your product at a port. Build the query first and let the data model follow from it.

Where these projects fail

Three patterns, all of which we have been called in to fix rather than prevent.

• One lot code per truck. It is the easiest thing to implement and it destroys the entire point. The moment a truck carries product from four ponds under one code, your traceability granularity is the truck, and a recall takes all four farms with it.
• Retrofitting identity downstream. Attaching pond data at the plant by matching on arrival time and supplier name works until two consignments arrive within an hour of each other. Then it works badly and nobody notices for a year.
• Assuming connectivity. If the capture app requires a network round trip to save, field agents will record on paper and enter it later, in batches, from memory. You will have a database full of records that look precise and are not.
• Treating the exporter's system as the source of truth. The record that matters was created at the pond by someone who does not work for you. If your architecture assumes the plant's ERP is authoritative and the farm data is an import, every disagreement resolves in favour of the wrong party, and the farmer stops correcting it.

None of these are exotic. They are what happens when a compliance system is specified by people who have never stood at a pond at 5am.

When you should not build this

If you are a small exporter running a handful of lots a month from ponds you own directly, you do not need a platform. A disciplined spreadsheet and your processor's existing system will satisfy the record requirements, and the honest advice is to spend the money on residue testing instead.

The case for building changes when three things are true at once: you source from farmers you do not own, you run enough lots that reconciliation is manual work, and a single rejected consignment costs more than the system. Below that line, this is a buy-or-do-without decision, not a build one.

It is also worth saying plainly that traceability software does not stop a residue failure. It tells you which pond it came from, quickly, and limits what you have to withdraw. Those are different problems and vendors routinely conflate them.

What to do with the thirty months

If you are going to need this, the order of work is not the order most teams choose. Capture comes first, because it is the part that depends on human behaviour and therefore takes longest. The records layer, the integrations into processor and buyer systems, and the reporting come after, because they are ordinary engineering.

A reasonable sequence: get pond-level identity captured at harvest and prove it holds for a full season; build the lot ledger and the transformation model around what you actually captured; then wire it to the plant and the buyer. Doing it in the reverse order produces a beautiful system with nothing trustworthy in it, which is the outcome the 2028 date is quietly encouraging.

The deadline moved. The season did not, and you get one harvest cycle per year to learn whether your capture works. That is the number to plan against — not July 2028.