Every other page about traceability describes how to build the capability. This one describes the only way to find out whether you actually have it: pick a lot, start a timer, and try to answer, from records alone, what went into it and where it went. Nothing else tells you the truth. Not a completed binder. Not a certifier’s checklist with every box ticked. Only the exercise itself.
A mock recall is a rehearsal for a request you hope never comes — a regulator or a buyer asking you to account for a specific lot, under a deadline, because something downstream has gone wrong. Farms that have never run one tend to believe they would pass. Most that then run one are wrong, and not because their records are incomplete. Because the records were never asked to work together before, and the first time anything is asked to work together is a bad time to discover it can’t.
The timer a real buyer or regulator sets is not this page’s to guess. Some contracts specify a response window in hours; some regulators’ expectations are looser but still real. Read your buyer’s specification and ask your certifier what window actually applies to you before treating any number here as a target.
The test is honest only if the lot is chosen badly
It is tempting to test the lot you remember best — last week’s harvest, still fresh, still traceable by memory even if the paperwork is thin. Resist it. That lot will pass regardless of whether your system works, because you are still the fallback the system is supposed to replace. The lot that matters is the one nobody remembers: a pallet from four months ago, sold to a customer whose name means nothing to you until you look it up.
Pick it by a method that cannot be gamed — a die roll against a list of harvest dates, or literally the oldest lot still within your retention window. The goal is to simulate the one property a real recall always has and a rehearsal is tempted to skip: nobody involved remembers anything, and the record has to stand entirely on its own.
Run both directions, because a recall needs both
A trace has two halves, and passing one while failing the other is still a fail. The backward half asks what went into the lot: which planting it came from, which inputs were applied to that planting, and when. The forward half asks where the lot went: which customers received part of it, and how much each got — the subject of recording shipments and customers.
Most farms that have never rehearsed discover they are stronger in one direction than the other, usually backward, because the harvest and input records were written by the same person on the same day and naturally reference each other. The forward trace is the one that decays, because a sale feels like the end of the story rather than a record that still owes something to the lot it came from. Test both, every time, even if you suspect one will pass.
Start the clock before you touch a single record
The exercise is not the trace. It is the trace under time pressure, and skipping the clock turns a rehearsal into a leisurely filing review that tells you nothing about the day it counts. Set a timer to whatever window is realistic for your buyers — see the note above — and do not stop it to think. A real request will not pause either.
Note every place the clock advances for a reason that has nothing to do with the actual trace: time spent finding which binder a record lives in, time spent calling someone to ask what a handwritten note means, time spent reconciling two spellings of the same lot code. Those minutes are the finding. The eventual correct answer is not in doubt for most farms — the ability to produce it in time is.
Write down where the time actually went, not just the total. A farm that spends thirty minutes searching for a binder and five minutes reading it, once the binder is found, has a filing problem, not a recordkeeping problem, and the two are fixed in entirely different ways — one is a shelf, the other is a form.
The failure is almost always one broken join, not missing diligence
When a mock recall fails, the instinct is to conclude the farm needs to keep better records generally. That is usually the wrong diagnosis, and it leads to the wrong fix — writing down more, everywhere, which does not address anything. Look instead for the specific point where the chain of references breaks: a lot code on the harvest sheet that was never copied onto the invoice, or a planting record with no link to the input applications made against it.
The fix for a broken join is narrow and specific — one field added to one form, one habit changed at one step — where the fix for “keep better records” is vague and does not tell anyone what to do differently on Monday. Farms that run a mock recall and find one broken join, fix it, and re-run the same lot a month later usually pass the second time. That is the entire value of the exercise: it converts a vague fear into a specific, fixable defect.
What makes the rehearsal worth repeating
A single mock recall tells you about one lot and one moment. Its real value comes from repetition — run against a new lot each season, ideally by someone other than whoever ran it last time, so the exercise also tests whether the trace depends on one person’s knowledge rather than on the records themselves. A trace that only one employee can complete has the same weakness as no trace at all; it has simply moved the single point of failure from a missing record to an irreplaceable person.
Keep a short written log of each rehearsal — the lot chosen, the time it took, and the single join that broke, if one did. Read back three years of that log and you have something more useful than any individual result: a trend line showing whether the gap is closing or simply moving from one weak join to the next.
For the underlying argument about why this capability matters and what a joined record looks like, see the traceability guide. For the full set of related practices, the traceability hub links out to each piece of the chain this exercise tests.
What a joined record changes about the clock
Everything above holds whether your records live on paper or in software — a mock recall tests the join, not the tool. Where a product changes anything is speed: Farm40 joins a harvest lot to the input applications made on its planting and to the customer sales that reference its lot code, so the trace that used to mean matching codes by eye across three binders becomes a single export. The honest limit sits in the same sentence as the capability — the forward half of that join is a lot-code string match, so a sale entered with a blank or mistyped code will not appear, and the export can only surface a join that was actually made at data entry. It shortens the clock. It does not replace the rehearsal, because the only way to know the clock is actually short is to run it.