> 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/thermal-imagery-ai/critical-control-points/incoming-goods.md).

# Incoming Goods

Critical Control Point (CCP #1)

*Food Safety Management System (FSMS) – Technical Documentation*

***

### 1. Introduction

#### Why Incoming Goods is a Critical Control Point

The incoming goods stage is the first and most crucial barrier against food safety risks entering the facility. It is formally designated as Critical Control Point #1 (CCP #1) under HACCP systems because it represents the last external link in the food supply chain—where unverified products, if not carefully checked, can introduce unacceptable risks into internal processes.

Failure to control this step compromises downstream safety, making early intervention essential for managing temperature abuse, labeling errors, or contamination from suppliers or transport conditions.

***

### 2. Hazards

#### Common Hazards Identified at Receipt

Typical hazards flagged during HACCP risk analysis include

#### Microbiological Hazards

* Growth of pathogens (*Listeria*, *E. coli*, *Salmonella*) due to elevated temperatures
* Spoilage organisms from exposure to ambient conditions

#### Other Hazards

* Physical: Broken seals, damaged containers, foreign objects
* Chemical: Residual sanitation agents, allergens, or transport chemical exposure
* Labeling/Allergen: Incomplete or incorrect allergen declarations, language errors

Based on likelihood, severity, and the ability to control, incoming goods are frequently identified as a CCP and require both real-time monitoring and robust documentation.

***

### 3. HACCP Audit Table

#### Monitoring & Critical Limits

| Step           | Hazard                                 | Control Measure                 | CCP? | Critical Limit        | Monitoring Method                     |
| -------------- | -------------------------------------- | ------------------------------- | ---- | --------------------- | ------------------------------------- |
| Incoming Goods | Pathogen growth                        | Temperature verification        | Yes  | ≤ 5°C (chilled foods) | Thermal imaging / thermometer         |
|                | Document errors / lack of traceability | Invoice image capture & linkage | Yes  | Required per delivery | AI text extraction + metadata linking |
|                | Labeling inaccuracies                  | Product label image capture     | Yes  | Visual confirmation   | Image with AI-assisted field mapping  |

<br>

***

### 4. Workflow

#### Image-Based Evidence, AI Analysis & Invoice Anchoring

1. Start with Invoice Image:
   * Take a photo of the delivery invoice or delivery docket.
   * AI extracts: supplier, purchase order, dates, product list, document number.
2. Capture Product Images:
   * Image of each delivered item (e.g., seafood, meat, produce).
   * Images automatically link to the previously captured invoice.
3. AI-Powered Data Extraction:
   * Temperature (if thermal image)
   * Food type / label contents
   * Use-by dates, halal/kosher indicators, packaging condition
   * Vehicle condition (cleanliness, integrity) with optional vehicle photo
4. Automatic Form Submission:
   * Each image triggers a new operation instance.
   * Fields are auto-populated based on AI results.
   * Submissions are automatically stored in the Didge platform.

***

### 5. Submission & Reporting<br>

All submissions are stored in the Didge Platform, which is a secure, cloud-based system that supports:

* Real-time data availability
* Automatic backups and data integrity
* Centralized access for compliance teams and auditors

This structure enables:

* Instant generation of web reports for each operation instance
* Live performance dashboards for tracking submission volumes
* Data tables to aggregate and analyze:
  * Food temperatures
  * Supplier trends
  * Product condition insights
  * Non-conformance counts

***

### 6. Audit Readiness

#### ISO 22000, HACCP, Local Food Safety Regulations<br>

Because the Didge platform is cloud-native, it offers a modern, audit-friendly architecture:

* No manual data entry — reduces error rates and record falsification
* Photos as evidence — images serve as immutable, timestamped proof
* Large-scale data — submissions are far more comprehensive than paper or spreadsheet-based logs
* Export capabilities — PDF, CSV, and Excel files can be generated for audit presentation or archival
* Full traceability — each image is linked to its source invoice, forming a complete document chain

This supports seamless audits under:

* ISO 22000 (Food Safety Management Systems)
* Codex HACCP guidelines
* National Food Safety Acts or Health Department inspections

Auditors can view both summary data and deep drill-downs of individual records, complete with visual evidence.

***

### 7. Summary

#### Digitized, Verifiable, Scalable Control<br>

Incoming goods monitoring through the DIG platform delivers:

* Critical Control Point compliance with automation
* Traceability from document to product
* Temperature verification using thermal imaging
* Label and product detail extraction with AI
* Tamper-resistant, timestamped photographic evidence
* Audit readiness with real-time reports and large data sets<br>

This modernized approach not only enhances food safety but simplifies compliance management and builds trust across internal teams, regulators, and third-party certifiers.

***


---

# 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/thermal-imagery-ai/critical-control-points/incoming-goods.md?ask=<question>&goal=<user_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.
