> 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/checkpoint-structure/didge-platform-structure.md). # Didge Platform Structure Understanding Forms, Checkpoints, and Packages #### Purpose of this Document This document explains how the Didge platform is structured using Forms, Checkpoints, and Packages. It is intended to: * Provide internal clarity and consistency * Help clients understand how Didge adapts to different operations * Explain how simple and complex use cases are handled within the same platform This is not a pricing or licensing document. *** ### 1. The Core Building Blocks Didge is built using three core concepts: | Concept | What it is | Why it exists | | ---------- | --------------------------------- | --------------------- | | Form | A reusable data capture template | Consistency and reuse | | Checkpoint | A configured use of a form | Operational meaning | | Package | A logical grouping of checkpoints | System structure | A complete management system is assembled by combining multiple packages. *** ### 2. Forms #### Simple Explanation A form is how information is collected. It might be: * A temperature check * A cleaning checklist * A calibration record * A training acknowledgement Forms are reusable and generic by design. *** #### Technical Explanation A form defines: * Fields (numbers, text, photos, signatures) * Validation rules * Layout and flow * Data structure Forms do not define business meaning. Didge has over 500 forms that can be reused across different use cases, industries, and regulatory contexts. *** #### Real-Life Example Generic Temperature Check Form * Field: Temperature (°C) * Field: Pass / Fail * Field: Comment * Field: Photo (optional) This same form might be used for: * Fridge temperature * Freezer temperature * Hot holding temperature * Incoming goods temperature The *meaning* comes later. *** ### 3. Checkpoints #### Simple Explanation A checkpoint is a form used in a specific context. It answers: > “What is this check for, when does it happen, and what happens if it fails?” *** #### Technical Explanation A checkpoint wraps a form with: * Purpose (what risk is being controlled) * Frequency (daily, weekly, per delivery) * Thresholds and tolerances * Pass / fail logic * Corrective actions * Ownership and responsibility * Reporting and escalation rules * Regulatory mapping (where applicable) This is where business logic lives. *** #### Real-Life Example Using the same Generic Temperature Check Form: | Checkpoint | Meaning | | ---------------------------------- | ------------------------- | | *Daily Fridge Temperature Check* | Must be ≤ 5°C | | *Incoming Goods Temperature Check* | Must be ≤ 5°C at delivery | | *Hot Holding Temperature Check* | Must be ≥ 60°C | Same form. Different checkpoints. Different rules and outcomes. *** ### 4. Packages Packages group checkpoints together into meaningful sets. Didge supports two client-facing ways of grouping packages: * Packages by Function * Packages by Operation *** ### 5. Packages by Function #### Simple Explanation Packages by Function group checkpoints by subject-matter or control area. They answer: > “What control function does this manage?” *** #### Technical Explanation Packages by Function: * Represent a single risk or operational domain * Are stable and long-lived * Can be used at minimal or advanced depth * Contain checkpoints only (not forms directly) These are the structural backbone of the platform. *** #### Examples (By Function) * Calibration & Verification * Cold Storage Control * Incoming Goods Control * Cleaning & Sanitation * Cooking & Thermal Process Control * Training & Competency *** #### Example: Calibration & Verification (By Function) This single package can support very different realities. **Minimal use (small café)** * One weekly boil & ice calibration check * Manual pass / fail * Simple corrective action **Advanced use (large enterprise)** * Multiple equipment types (scales, probes, sensors) * Asset-based calibration schedules * External certificate uploads * Training verification * Audit-ready reporting Same package. Different depth. *** ### 6. Packages by Operation #### Simple Explanation Packages by Operation group checkpoints based on how a business actually operates day to day. They answer: > “What does my operation look like?” *** #### Technical Explanation Packages by Operation: * Combine checkpoints from multiple functional packages * Are curated for speed and clarity * Reflect real operational environments * Do not introduce new logic * Use existing forms and checkpoints They are convenience bundles, not new structure. *** #### Examples (By Operation) * Small Commercial Kitchen * Café / Restaurant * Hotel Food & Beverage Operations * Airline Catering Operations * Aged Care Food Services * Halal Kitchen Operations *** #### Example: Small Commercial Kitchen (By Operation) This package might include checkpoints from: | Function | Example checkpoint | | -------------- | -------------------------------- | | Incoming Goods | Basic delivery temperature check | | Cold Storage | Daily fridge temperature | | Cooking | Core cooking temperature | | Cleaning | Daily cleaning checklist | | Calibration | Manual boil & ice calibration | Each checkpoint is: * Simple * Low overhead * Easy to complete But structurally sound. *** ### 7. Minimal vs Advanced Use A key principle of Didge: > A package may be present even if only one or two of its capabilities are used. Small businesses often: * Touch many functional areas * Use each one very lightly Didge supports this without fragmentation. There are no “micro-packages”. *** ### 8. Reuse at Scale Didge deliberately separates: * Forms (data capture) * Checkpoints (meaning) * Packages (structure) This allows: * One form to support many use cases * One checkpoint to appear in multiple packages * One package to be used across many industries This avoids duplication and keeps reporting consistent. *** ### 9. Building Full Management Systems A site’s management system is assembled by: 1. Selecting one or more Packages by Operation 2. Adding or extending Packages by Function if needed 3. Configuring checkpoint depth, frequency, and rules 4. Applying regulatory or customer-specific requirements No redesign required as the business grows. *** ### 10. Growth Without Rebuild As an operation becomes more complex: * New checkpoints are enabled * Existing checkpoints gain more depth * Additional packages are added Forms remain the same. Historical data remains valid. No migrations required. *** ### 11. One-Page Mental Model > Forms collect data > Checkpoints give data meaning > Packages organise checkpoints > Operations assemble packages into a system *** ### 12. Why This Matters This structure allows Didge to: * Serve very small and very large organisations * Support multiple industries and jurisdictions * Reuse assets efficiently * Stay simple for operators * Remain robust for audits It is the foundation that allows Didge to scale without becoming fragile. --- # 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/checkpoint-structure/didge-platform-structure.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.