> For the complete documentation index, see [llms.txt](https://docs.didge.io/home/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.didge.io/home/checkpoints/incoming-goods/supporting-documents/overview.md). # Overview ### 1. Overview The Incoming Goods checkpoint governs the receipt and initial verification of food and food-contact items as they enter a facility. Its purpose is to ensure that all goods received meet defined food safety, quality, and compliance requirements before being accepted into storage or production. This checkpoint provides a controlled, auditable mechanism to identify non-conforming goods early, preventing downstream risks to food safety, compliance, and operational efficiency. ### 2. Where This Fits The Incoming Goods checkpoint sits within the Receiving domain and is typically the first Critical Control or Control Point in the food safety workflow. It occurs immediately after delivery arrival and before goods are moved into storage (e.g. chillers, freezers, dry stores) or released to production. The outcomes of this checkpoint directly influence subsequent checkpoints such as Storage, Preparation, or Cooking. ### 3. Intent and Outcomes The intent of the Incoming Goods checkpoint is to establish confidence that only compliant goods enter the facility. Desired outcomes include: * Compliance outcome: Verification against regulatory, supplier, and internal food safety requirements. * Operational outcome: Early identification of issues to avoid contamination, spoilage, or rework. * Reporting outcome: Creation of reliable, auditable records for inspections, audits, and trend analysis. ### 4. Use Case This checkpoint primarily supports the following scenarios: * Receipt of temperature-controlled goods requiring validation at delivery. * Verification of packaging integrity, labelling, and supplier documentation. * Acceptance, conditional acceptance, or rejection of delivered goods. ### 5. Problem Statement Without a structured Incoming Goods checkpoint, organisations face several risks: * Non-compliant or unsafe goods entering storage or production. * Inconsistent checks performed by different staff or shifts. * Lack of defensible records during audits or incident investigations. * Delayed detection of supplier or logistics issues that compound over time. ### 6. Solution Approach The Incoming Goods checkpoint introduces a standardised, repeatable assessment at the point of receipt. It defines what must be checked, how results are evaluated against limits or criteria, and how exceptions are handled. By capturing results digitally and linking them to corrective actions and evidence, the checkpoint creates a single source of truth for incoming goods compliance without prescribing operational detail. ### 7. Key Concepts and Definitions Key concepts relevant to this checkpoint include: * Acceptance criteria: Defined conditions under which goods may be accepted. * Limits: Thresholds such as temperature, packaging condition, or expiry requirements. * Corrective actions: Required responses when acceptance criteria are not met. * Evidence: Photos, notes, or documents that support decisions made at receipt. * Roles: Individuals responsible for performing checks and approving outcomes. ### 8. User Journey Summary At a high level, the Incoming Goods journey follows this flow: 1. Goods are received at the facility. 2. Required checks are performed against defined criteria. 3. Results are evaluated automatically or manually. 4. Any non-conformances trigger corrective actions. 5. Outcomes and evidence are recorded for traceability. ### 9. Outputs and Evidence The Incoming Goods checkpoint produces: * Digital records of each receiving event. * Logged results for all checks performed. * Exception and non-conformance records where applicable. * Linked evidence such as photos or comments. * Data available for reports, dashboards, and audit trails. ### 10. Scope and Assumptions This checkpoint covers the verification of goods at the point of receipt only. It does not replace supplier assurance programs or downstream storage and handling controls. It assumes that suppliers, delivery schedules, and basic receiving processes are already defined, and that users performing the checkpoint are appropriately trained. Configuration, user roles, and detailed procedures are addressed in the End User and Admin guides that follow. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.didge.io/home/checkpoints/incoming-goods/supporting-documents/overview.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.