> 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/packages/designing-packages.md). # Designing Packages Designing Packages, Checkpoints, and Forms in Didge This document explains how solutions are designed in Didge, using a clear and repeatable hierarchy: > Package → Checkpoint → Form It is intended for: * clients configuring or extending their Didge system * partners and implementers * internal teams (product, engineering, sales) This document focuses on *design intent*, not pricing or licensing. *** ### The Core Design Principle Didge is designed from the customer outcome backwards. This means: * Packages define *what the customer needs* * Checkpoints define *what controls are required* * Forms define *how data is captured* Each layer depends on the one above it. *** ### 1. Packages #### What is a Package? A package represents a major area of business control or operation. Packages answer the question: > “What area of my operation do I need to manage?” Packages are what customers recognise and select. *** #### Packages by Function Didge primarily designs packages by function (subject-matter area). Examples include: * Calibration & Verification * Cold Storage Control * Cleaning & Sanitation * Incoming Goods Control * Cooking & Thermal Process Control Each package: * represents a clear business outcome * defines the scope and boundaries of that outcome * can be implemented at different levels of depth *** #### Why Design Starts with Packages Starting with packages ensures that: * the system is aligned to real customer needs * solutions are outcome-focused, not feature-driven * complexity is controlled at the highest level Packages define the promise Didge makes to the customer. *** ### 2. Checkpoints #### What is a Checkpoint? A checkpoint is a specific operational control within a package. Checkpoints answer the question: > “What specific check or control must occur to support this package?” A package contains one or more checkpoints. *** #### What a Checkpoint Defines Each checkpoint defines: * the purpose of the control * who performs it * how often it occurs * what constitutes pass or fail * what happens if it fails * what evidence is required This is where business logic and operational meaning live. *** #### Example: Calibration Package Package: Calibration & Verification Example checkpoints: * Boil & Ice Point Calibration * Digital Sensor Calibration * Scale Calibration * External Certificate Verification Each checkpoint represents a distinct control intent, even if they use similar data. *** #### Why Checkpoints Come After Packages Packages are too broad to design data capture directly. Checkpoints provide: * clarity of purpose * operational boundaries * correct level of detail Without checkpoints, forms become overly specific or overly generic. *** ### 3. Forms #### What is a Form? A form is a reusable data capture instrument. Forms answer the question: > “How is the information for this checkpoint recorded?” Forms are intentionally generic. *** #### What Forms Define A form defines: * fields (numbers, text, photos, signatures) * validation rules * layout and flow * data structure Forms do not define business meaning. *** #### Form Reuse in Didge The same form may be used by multiple checkpoints and packages. For example: * one temperature form may support fridge checks, freezer checks, and delivery checks * one checklist form may support cleaning, maintenance, or verification activities Meaning is always supplied by the checkpoint, not the form. *** ### The Design Flow 1. Define the package (What business outcome is required?) 2. Define checkpoints within the package (What specific controls are needed?) 3. Select or design forms to support checkpoints (What data needs to be captured?) This flow applies whether designing: * a new package * a new checkpoint * a new form *** ### Minimal and Advanced Implementations A package may be implemented at different levels of depth. For example: * a small operation may use one or two simple checkpoints * a larger operation may enable many checkpoints with additional rules and evidence This does not require new packages or new forms — only deeper checkpoint configuration. *** ### Why This Matters Designing in this order ensures that Didge: * remains simple for small operations * scales cleanly for complex environments * avoids duplicated or hard-coded forms * preserves data consistency over time This structure allows Didge to grow without requiring rebuilds or migrations. *** ### One-Page Summary > Packages define outcomes > Checkpoints define controls > Forms capture data Always design in this order. *** ### Intended Use This document should be used as: * a reference on the Didge Docs site * guidance for solution design discussions * a shared language between Didge and its customers --- # 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/packages/designing-packages.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.