> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://tieback.io/docs/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://tieback.io/docs/_mcp/server. # Notices & Recall Model > The content model behind product safety notices: the three notice kinds, what a recall must contain, how targeting works, and the publication checks. Every communication produced by the module is a **notice**. This page sets out the shape of a notice, how it is targeted, how its status is derived from its live window, and what has to be true before it can be published. ## Notice Kinds | Kind | Use it when | Content requirements | | ------------------ | ------------------------------------------------------------------- | ----------------------------------------------------- | | **Recall** | The product presents a safety risk and must be recalled or remedied | Strictest: full hazard, risk, consumer action, remedy | | **Safety alert** | A safety-relevant warning that stops short of a full recall | Hazard and consumer action | | **Product update** | A non-safety update about the product | Lightest: cannot use recall wording | The kind chosen at the start of authoring determines which fields are required to publish and which wording is permitted. A product update cannot borrow recall language, and a recall cannot be published without at least one remedy on offer. ## What a Recall Must Contain Aligned to the GPSR recall-notice obligations (Reg. (EU) 2023/988, Arts. 35–37), a recall is only publishable once it carries: * a clear consumer-facing **title** and summary that identify the product as subject to a safety recall * the **hazard**: what is wrong with the product * the **consequence**: the risk to the consumer * the **consumer action**: what the consumer should do, including whether to stop using the product immediately * one or more **remedy options** and, where relevant, remedy instructions * a **contact** point (email or link) for affected consumers * the **affected products** and, where relevant, the **affected batches** * the **markets** the product was sold in * at least one **image** of the affected product These requirements are enforced at publication (see [Publication Checks](#publication-checks)). ## Targeting A notice targets the units actually affected, following a product-first hierarchy: | Level | What it targets | Availability | | ----------- | ------------------------------------------------ | ------------ | | **Product** | Every unit of the selected product | Live | | **Batch** | A specific production batch (GS1 batch/lot code) | Live | | **Serial** | An individual unit by serial number | Planned | A single notice can combine product-level and batch-level targets, for example, all units of one product together with two specific batches of another. Batches are chosen from the product's own production batches by their real GS1 batch/lot code, so a recall can never reach units that were never part of an affected batch. When a product target is added, the product's identity, covering its name, brand, GTIN, SKU, and model, is captured on the notice at that moment. The notice keeps that record even if the underlying product catalogue is later edited, so what was recalled is preserved exactly as it was at the time. ## Status & Live Window Publishing is always a deliberate action by an authorised user. At publication the brand sets an optional **live window**: a start date (when the notice should begin showing to consumers) and an end date (when it should stop). Nothing runs on a timer to change the notice's state. A notice's public status is **derived from that window each time it is read**: | Status | Meaning | | ------------- | --------------------------------------------------------- | | **Draft** | Being prepared; not public | | **Scheduled** | Published with a start date in the future; not yet public | | **Live** | Within its live window; shown to consumers | | **Expired** | Past its end date; no longer shown to consumers | | **Revoked** | Withdrawn by the brand; no longer public | Only a **Live** notice is shown to consumers. A notice can be published ahead of time with a future start date so it is fully prepared but does not appear to the public until its window opens. ## Localisation A notice is authored once in a base language and prepared for each language of the markets the affected products are sold in. Every language version passes the same language check as the base before the notice can be published. See [Localisations Overview](/localisations/overview). > Automated translation of a recall into every target-market language is rolling out. Preparing each language manually is always available. If the base content is edited after language versions have been prepared, the auto-prepared versions are marked as needing review so an out-of-date translation can never be shipped to consumers. Manually written versions are left as-is. ## Publication Checks Before a notice can be published, two gates must pass: 1. **Completeness**: every required field for the notice's kind is present (see [What a Recall Must Contain](#what-a-recall-must-contain)). 2. **Language check**: every language version has passed the wording check, which enforces compliant language and blocks prohibited or misleading terms. If either gate fails, publication is blocked and the missing requirement is shown to the author. When a notice is published, an immutable record of its content at that moment is retained so the brand can later prove exactly what was published, when, and by whom. ## Related Docs * [Product Safety and Recall Overview](/product-safety-and-recall/overview) * [Consumer Experience](/product-safety-and-recall/consumer-experience) * [Localisations Overview](/localisations/overview) * [Minting Overview](/minting/overview) * [Identifiers](/product-module/identifiers)