Most traceability failures announce themselves. A blank field on a harvest sheet, a sale with no lot code, a missing invoice — these are visible the moment anyone looks. Commingling is the one failure mode that does not announce itself, and that is exactly what makes it the most dangerous thing on this list. A commingled lot with every field filled in looks like a perfect record. It is a perfect record of a fact that is no longer true.
The moment product from two lots joins in the same bin, the same wash tank, or the same carton, you no longer have two lots. You have one lot, and its history is the union of both. If your paperwork still lists them as separate — two harvest entries, two lot codes, each looking clean — the paperwork is describing a separation the product itself no longer has.
Commingling is not the mistake — silence about it is
It is worth saying plainly: mixing product is not wrong. A pack line exists to combine volume from several plantings into a workable run, and a grain bin exists to hold more than any single truckload. Almost every operation above a certain size commingles somewhere, and demanding that it never happen is not a realistic standard.
What is wrong is commingling that leaves no trace of itself. The instant two lots combine, that combination is itself an event with the same standing as a harvest or a sale — it changed what exists. Treat it that way: write down that the merge happened, which lots went in, and assign the resulting product a new code. Skip that one line, and the records keep asserting a purity the bin has already destroyed.
Think of it the way you would think of a financial ledger. Combining two accounts is a legitimate transaction, but only when it is entered as a transfer, with both account numbers referenced. Combining them and then continuing to report the old balances separately, unchanged, is not an accounting choice — it is simply wrong, and the fact that it happened without anyone intending deception does not make the resulting ledger any more accurate.
A commingled lot without a new code is a false record, not a missing one
There is an important difference between these two failures, and it changes how you find them. A missing record announces itself as a blank — anyone auditing the file sees the gap immediately. A commingled lot with no new code assigned announces nothing. Every field is filled in. Every code is present. Every one of them is quietly wrong, because each still claims to describe product that, in reality, no longer exists in isolation.
You typically discover this failure only the hard way: a trace on one of the two original lots comes back implicating a customer who never should have been reached, because the mixed product actually shipped under the wrong code, or under both codes inconsistently. By the time that surfaces, the mixed lot has usually already sold through. This is the reason a mock recall matters more for commingled products than for almost anything else — it is the only rehearsal likely to catch a false record before a real one does.
Draw the merge boundary at the point of no return
The practical question is where, physically, a merge actually happens, because that is where the new code has to be assigned. For produce, it is usually the wash tank or the pack line — the point after which two lots can no longer be physically separated even if someone wanted to. For grain, it is the bin: once two truckloads sit on top of each other, there is no undoing it, and the new code belongs to the bin’s contents from that point forward, not to either truckload individually.
Assign the new code at that exact point, not before it and not after it. Assigning it too early — before the merge actually happens — creates a code for something that does not yet exist. Assigning it too late — after product has already shipped under the old codes — means some of what left the building carries a code that no longer accurately describes what is in the box.
A useful habit is to walk the physical process once, on foot, and mark every point where two streams of product could plausibly join — every shared bin, every shared tank, every shared belt. Most farms find fewer such points than they expect, often just one or two, and each is a place worth a sign or a checklist step reminding whoever works there that a merge event needs a line in the log, not just product moving from one place to another.
The new code has to point backward to both parents
A merged lot’s code is not a fresh start; it is a pointer with two parents instead of one. The record behind it should read like a small family tree: lot C, formed from lot A and lot B, on this date, in this bin. Anyone tracing C backward should land on both A and B, and anyone tracing A or B forward should land on C, not on a dead end. This is the same discipline covered for individual lot codes — a code only works if it is carried forward consistently — extended to the case where forward means two paths converging into one.
Skipping this step is the single most common way a farm that diligently assigns lot codes at harvest still fails a mock recall later. The codes were never wrong. They simply stopped being true the moment a bin or a wash tank merged them, and nothing in the paperwork recorded the moment it happened.
Where a linked record can catch the gap before a trace does
Recording a merge is a habit no software can force by itself — it depends on someone at the wash line or the bin recognizing that a merge is happening and writing it down. Where Farm40 helps is after that: because harvest lots, the plantings behind them, and the sales that follow are stored as linked records rather than separate documents, a merged lot entered with both parent codes keeps its full backward trace intact through the traceability packet export, rather than silently pointing at only one parent. The limit is the same one that runs through every join in the system — it can only record a merge that someone actually enters; it has no way to infer that a bin was mixed if nobody logged it. The discipline of recording the merge itself has no substitute, in software or out of it. For the fuller picture of how lot integrity fits into traceability generally, see the traceability guide.