A carton gets pulled aside at a receiving center. Two days later someone asks what happened. The answer arrives as a sentence: "the bags were wrong." Nobody can say which bag, against which rule, or what it cost, and the conversation quietly becomes about who to believe.
That is the failure mode I want to write down, because it is not a packing failure. The packing failure already happened and was fixable in ninety seconds. The failure that costs money is that the evidence was destroyed by the fix.
What a defect actually is
Almost every prep defect on goods coming from China is a measurement, not a judgment. A bag opening of five inches or more needs a suffocation warning printed on it, and the film has to be at least 1.5 mil. Expiration dates have to read MM-DD-YYYY or MM-YYYY, at 36 point or larger, on the unit and on the box. A standard carton stops at 36.00 by 25.00 by 25.00 inches and 50.00 pounds. Case packs cap at 150 units. A supplier carton whose previous carrier barcode is still scannable is a defect even when everything inside it is perfect.
Each of those is a number, an observed value, and a source. That is a record. A record can be replayed, audited and argued with. "The bags were wrong" cannot.
The record has to be captured before the rework
This is the part that is easy to get wrong for an understandable reason: fixing the item feels like the job, so the operator fixes it and then reports that it was fixed.
Rework is irreversible. The moment the opaque poly bag is cut open and the item goes into a compliant one, the only surviving proof of what arrived is whatever was captured first. So the capture has to be a step that gates the rework, not a form filled in afterwards.
The shape we keep it in is deliberately boring. One row per finding, and the row is written before anything is touched:
{
"findingId": "f-2026-10-07-0142",
"cartonRef": "inbound-carton-88213",
"ruleCode": "suffocation_warning",
"channel": "amazon-fba",
"expected": "warning text present on bags with opening >= 5in, film >= 1.5 mil",
"observed": "opaque bag, no printed warning, opening 8in",
"sourceUrl": "https://sellercentral.example/help/prep/bagging",
"sourceSeen": "2026-10-01",
"evidence": ["88213-bag-front.jpg", "88213-bag-scale.jpg"],
"measured": { "openingIn": 8.0, "filmMil": null, "weightLb": 41.2 },
"disposition": "rework",
"reworkedAt": null,
"costBearer": null
}
Three fields are the ones people leave out and later need.
sourceSeen is the date somebody actually read the rule. Without it, a rule change silently rewrites history and you cannot say what standard the item was judged against at the time.
evidence is an array, not a boolean. One photo of a bag on a bench proves the bag exists. The second photo is the one that shows the tape measure across the opening. If the finding is a measurement, the evidence has to contain the measurement.
costBearer stays null until someone with authority decides who pays a preparation defect fee. Leaving it blank is a fact. Guessing is a policy you did not agree with anybody.
The test that makes this real
Write it as a dispute test rather than a unit test:
Someone claims a carton was rejected on 14 March. Open the record for that carton. Can you state the rule, the observed value, the version of the rule that was in force on 14 March, and what was done, without asking anyone who was on shift that day?
If the answer is no, your prep process is a memory system with a database attached. The database stores the outcome. The memory stores why, and memory does not survive staff turnover.
The corollary is uncomfortable but useful: a fix you cannot see is a service you cannot audit. Any provider who reports "handled" without a row behind it is asking you to take the relationship on trust, and trust is the wrong instrument for a per-carton process.
What this changes upstream
Once defects are records instead of stories, the aggregate becomes readable. Five rows with ruleCode: "expiration_date_format" from the same manufacturer is not a prep problem, it is a coding-convention problem at the factory, and the fix belongs in the purchase order rather than at a packing bench. A row with ruleCode: "preexisting_barcode" on every carton from one supplier means the inbound is arriving in retail-ready packaging that has to be broken down, which is a decision to make before you buy, not after.
That is the actual value of the record. It is not that you can win an argument, although you can. It is that the defect log tells you which upstream decision to change, and a log of "bags were wrong" tells you nothing.
What to ask your provider
Ask what they capture before reworking, and ask to see one row. Ask whether the rule they applied is versioned with the date they read it. Ask who is named as the payer when the defect is theirs, and whether that decision is in the row or in an email. Ask what happens to the evidence file if you leave after six months.
Four questions, and the answers are either records or stories.
FulfillNexa by SBT (fulfillnexa.com) runs inbound, storage and outbound across three warehouses in China, with 3,000 square meters in Shenzhen, 13,000 in Suzhou and 8,000 in Dongguan, and the reason we keep writing these shapes down is that a prep dispute is settled by the record and by nothing else. We do not publish rates or transit commitments, and none of the above depends on either.
Top comments (0)