> 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/foodcore-sensors/end-user/core-functions/compliance.md).
# Compliance
***
### 1. Overview
The **Compliance Feature** of the wireless temperature monitoring system ensures adherence to food safety programs, particularly at **Critical Control Point (CCP) 2**, which pertains to cold and frozen storage. In a typical food safety framework, temperature control is vital to mitigating **microbiological hazards**, making this feature central to daily verification processes.
Digital sensors collect temperature data roughly every **20 minutes**, leading to a vast volume of data. The compliance feature refines this data into **twice-daily values** (AM and PM) that are audited against program thresholds.
***
#### Time Frames and Thresholds
* **AM window**: 00:00 to 12:00
* **PM window**: 12:00 to 00:00
Temperature thresholds (or **critical limits**) are:
* **Cold storage**: ≤ 5°C (commonly 4°C)
* **Frozen storage**: ≤ -15°C (commonly -18°C)
***
### 2. Data Logic
For each unit, the system attempts to find a **compliant temperature value** (ambient or probe) within the defined window:
* **Pass**: At least one compliant value is found within the AM or PM range
* **Fail**: No compliant values within the window
**Compliance logic options**:
* Use **Ambient** only (OR logic)
* Use **Probe** only (OR logic)
* Use **Both** (stricter, requires both values within threshold, AND logic)
Thresholds and logic type are configurable during implementation and editable by **admin users**.
***
### 3. Compliance Dashboard
**3.1 Graphical Trends**
* **Bar chart**: Number of non-compliant units per day split by AM and PM
* **Line chart**: Total daily non-compliances
* **Time Filter**: Defaults to last 7 days; can be adjusted
**3.2 Worst Performer Summary**
* A horizontal bar chart on the right side of the dashboard highlights the two units with the highest counts of non-compliance over the selected period.
* Useful for **targeted maintenance** and resource allocation
**3.3 Compliance Grid Table**
A date-by-device grid view for the selected period.
* Each row = a monitored unit (device name + DevEUI)
* Each column = a date (e.g., 9/3, 10/3 … 15/3)
* Each cell is split diagonally; hover over the result to see the recorded temperature data.
\
✓ Green tick = Compliant
\
✗ Red cross = Non-compliant
*"Each cell is split diagonally: AM is top-left, PM is bottom-right."*
Use the ← → navigation arrows to scroll through date ranges. Use the Search Label / DevEUI field to filter to a specific device.
**3.4** Detailed Records Table
A full log of individual compliance check records is displayed below the grid. Use the “View More” or “Hide” button to expand or collapse this table.
Displays data per unit:
* Unit Name
* Unique Sensor ID (DevEUI)
* Ambient & Probe readings
* Compliance status (green tick / red cross)
* Schedule time and actual record time
Additional features:
* **Hovering** on the unit name opens a modal with recent sensor data
* **Pagination** for historical records
* **Filters**:
* By label or DevEUI
* Compliance only / Non-compliance only
***
### 4. Site-Wide Compliance
From the **site or department view**, a global Compliance Dashboard is accessible.
**Features:**
* **Same visualizations** as local dashboards but applied to the entire site
* **Non-Compliance Bar Chart**
* **Worst Performers List**
* **NC by Category Pie Chart**:
* Segments by deviation: 0-1°C, 1-5°C, 5-10°C, 11-20°C+
* Pie segments are clickable for filtering
* **Data Table** includes “**Out By**” column (degree variance from limit)
* **Filters by variance range** to group issues by severity
***
### 4. Daily Email Summary
A system-generated daily email summarizes:
* AM and PM compliance overview (pie chart + bar chart)
* Attached spreadsheet with:
* **Compliant unit summary**
* **Non-compliant unit details**: timestamps, unit names, temperatures, thresholds
Recipients include key staff like **chefs**, **food technologists**, and **hygiene managers**.
***
### 5. Summary
The Compliance Feature transforms high-frequency sensor data into actionable, auditable compliance records. It supports both localized and global overviews of temperature control, aligned to food safety CCP and OPRP requirements. With visual insights, filtering, and automatic daily reporting, it empowers proactive risk management in food environments.
---
# 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/foodcore-sensors/end-user/core-functions/compliance.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.
