> ## Documentation Index > Fetch the complete documentation index at: https://docs.closient.com/llms.txt > Use this file to discover all available pages before exploring further. # Lot-Scoped Recalls > Which GS1 Application Identifiers a lot-managed product needs so a recall can be scoped to specific lots, and how resolver rules turn that identity into scan-time recall status. A recall is only as precise as the identity printed on the product. If the finest-grained identifier a scanner can read is a GTIN, then every unit of that GTIN is indistinguishable at the point of sale, and the only safe scope for a recall is all of them. Encoding the lot alongside the GTIN is what makes a narrower scope provable. This page covers which Application Identifiers (AIs) to encode for lot-managed goods, what each one buys you during a recall, and how Closient resolves recall status per lot. > For a worked case study of what the absence of this layer costs, see [The 2026 Lettuce Recall Was Scoped by a Date Printed in Ink](https://blog.closient.com/lettuce-recall-scoped-by-ink/) on the blog. ## The minimum viable recall identity Most food and beverage products are lot-managed rather than serialized: units are produced and tracked in batches, and individual units carry no unique identity. For these products three AIs are enough to make a recall surgical. | AI | GS1 meaning | Why it matters in a recall | | ---- | ---------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | `01` | GTIN | Identifies the product. On its own it cannot distinguish one batch from another. | | `10` | Batch/Lot number | The unit of recall. This is the field that lets a recall cover some units and not others. | | `15` | Best Before Date | Frequently the field a public recall notice actually uses to describe affected stock, because it is already printed for consumers. | A Digital Link URI carrying all three looks like this: ``` https://id.closient.com/01/00012345678905/10/L2026-1842/15/260803 ``` `10` is the load-bearing one. A Digital Link with only `01` is a more capable UPC: it reaches a product page, and it can tell you nothing about which unit you are holding. ### Why AI 15 as well as AI 10 Including the best before date is not redundant. Recall notices are routinely written against a date range rather than a lot list, because the date is the thing a consumer can read off the pack and a lot code often is not printed on consumer packaging at all. Encoding `15` means a scan can answer the recall as it was actually worded, without the consumer having to find and interpret a case-level lot code. `15` renders to consumers as **Best if Used By**. See [AB 660 / Date Labels](/guides/ab-660-date-labels) for the full AI-to-phrase mapping and the banned-phrase validation applied on product registration. ### When to add AI 21 Add the serial number (`21`) only when units genuinely carry unique identity - pharmaceuticals under DSCSA, high-value goods, warranty-tracked items. For lot-managed produce and most packaged food, serialization is neither economical nor necessary: the recall scope is the lot, so the lot is the right granularity. Encoding a serial you cannot actually track per unit adds characters to the barcode and buys nothing. Every added AI lengthens the encoded string and therefore the printed symbol. See [QR Code Sizing](/user-guides/qr-code-sizing) for what each field costs in module count and minimum X-dimension before committing to a payload. ## How recall status resolves per lot Closient evaluates resolver rules against the AIs present in the incoming request, so a rule can be scoped to a lot without touching the rest of the catalog. 1. **A recall is recorded against specific lots** of a GTIN, either entered directly or matched from an ingested regulatory notice. 2. **Scans carrying `10`** are matched against those lots. A scan of an affected lot resolves to the recall destination; a scan of any other lot of the same GTIN resolves normally. 3. **Scans carrying only `01`** cannot be attributed to a lot. These fall back to the product-level treatment configured for the recall, since the system cannot prove the unit is unaffected. 4. **When the recall is lifted**, the rule is withdrawn and affected lots resolve normally again, so a re-scan shows the all-clear without a new label or a new code. Point 3 is the practical argument for encoding `10` at print time rather than planning to add it later. Recall behavior degrades to product-wide for any unit that does not carry a lot, which is the same blunt outcome as having no Digital Link at all. See [Resolver Rules](/user-guides/resolver-rules) for rule precedence and configuration, and [Check Recalls](/agent-skills/check-recalls) for querying recall status programmatically. ## Supply-chain events Scan-time status answers "is this unit recalled." Scoping the recall in the first place means knowing which lots went where, which is what EPCIS events provide: capture at pack, ship and receive, and the question "which locations received these lots in this window" becomes a query rather than a records request. This is also the shape of what the FDA's FSMA 204 rule requires for foods on the Food Traceability List - traceability lot codes, key data elements at critical tracking events, and records producible within 24 hours. The compliance date is July 20, 2028, extended from January 20, 2026. See [EPCIS Events](/guides/epcis-events) for capturing and querying them. ## What to do before your next print run * Confirm whether each product is lot-managed or serialized, and encode `10` or `21` accordingly - not both by default. * Add `15` for anything with a consumer-facing best before date, so a date-scoped recall notice is machine-answerable. * Check the resulting payload length against your label's available area before committing to the artwork. * Register the lots you produce, so that a recall entered against a lot has something to match. None of this changes what you print in human-readable text. It changes whether a machine can act on it.