> 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/checkpoints/about-settings.md). # About Settings Designing and Configuring Checkpoints in Didge ### Purpose of This Page This page explains what a Checkpoint is in Didge, how checkpoints sit between Packages and Forms, and how checkpoints are created by configuring forms. It is intended for: * internal teams (product, engineering, implementation, QA) * solution designers and partners * clients who want to understand how Didge turns forms into real business controls This page focuses on checkpoints and their relationship to forms and packages. *** ### What Is a Checkpoint? In Didge, a Checkpoint is a configured instance of a form that has been given business context. A checkpoint exists when: * a form has been selected * configuration has been applied * business rules have been defined > A form becomes a checkpoint only after it is configured. Until configuration occurs, a form is just a reusable instrument. *** ### The Role of Checkpoints in the Didge Model Checkpoints sit at the centre of the Didge framework: * Packages define *why* controls are needed * Checkpoints define *what specific control exists* * Forms define *how data is captured* Checkpoints are where: * business meaning is applied * operational behaviour is defined * reuse becomes safe and scalable *** ### Checkpoints as the Execution Layer A checkpoint represents a real-world action or control such as: * recording a temperature * verifying a delivery * completing a cleaning task * confirming a certificate is current Checkpoints are what operators actually interact with. *** ### How Forms Become Checkpoints Forms in Didge are deliberately designed to be: * reusable * neutral * context-free A form becomes a checkpoint when it is assigned to a package and configured. This configuration step is essential. *** ### Checkpoint Configuration (Admin Perspective) When a form is added to a package, the administrator is presented with a Checkpoint Settings area. This is where the form is transformed into a business-specific control. Typical configuration includes: * naming the checkpoint * adding instructional content or checklist text * enabling or disabling sections of the form * defining required vs optional fields * setting frequencies or schedules * defining pass/fail logic * setting critical limits or thresholds * configuring regional or regulatory variations Once saved, this configuration defines the checkpoint. *** ### Configuration Is Stored with the Checkpoint Checkpoint configuration is: * saved at the package level * versioned as part of the package definition * reused consistently wherever the package is deployed This ensures: * consistent behaviour across sites * predictable implementation * reduced configuration effort during rollout *** ### From Package to Implementation The lifecycle of a checkpoint is: 1. A Form is selected 2. The form is configured within a package 3. The configuration is saved as a checkpoint definition 4. The package is deployed to a site 5. The checkpoint appears with its predefined behaviour At deployment time: * no additional configuration is required * the checkpoint behaves exactly as defined *** ### Example: Temperature Checkpoint Form: Generic Temperature Entry Form Configured as a Checkpoint: Daily Fridge Temperature Check Configuration may include: * acceptable temperature range (e.g. ≤ 5°C) * required frequency (daily) * mandatory corrective action on failure * instructional text for staff The same form could also be configured as: * Incoming Goods Temperature Check * Freezer Temperature Check Each is a different checkpoint with different settings. *** ### Example: Certificate Currency Checkpoint Form: Credential Record Form Configured as a Checkpoint: Supplier Certificate Currency Check Configuration may include: * required certificate types * expiry or review date rules * reminder timing * consequences of expiry The same form could be reused for: * staff training currency * licence or permit review *** ### Why Configuration Belongs at the Checkpoint Level Placing configuration at the checkpoint level ensures: * forms remain reusable * packages remain understandable * business logic is not duplicated It prevents: * form sprawl * hard-coded rules * inconsistent behaviour across sites *** ### Checkpoints and Package Sophistication A package may include: * a small number of simple checkpoints, or * a large number of complex checkpoints Sophistication is achieved by: * adding more checkpoints * increasing configuration depth Not by creating new forms or packages unnecessarily. *** ### Relationship to Functional and Operational Packages Checkpoints: * are defined within Functional Packages * are composed into Operational Packages The same checkpoint definition may be used: * across multiple operational contexts * at different sites This ensures consistency without rigidity. *** ### Key Design Rules for Checkpoints * A form is not a checkpoint until it is configured * All business logic belongs to the checkpoint * Forms must remain neutral and reusable * Configuration should be saved once and reused * If logic feels too complex for a package, it belongs in a checkpoint *** ### One-Page Summary > Packages define *why* > Checkpoints define *what and how* > Forms capture data A checkpoint is created by configuring a form within a package. *** ### Intended Use This page should be used as: * guidance for designing checkpoints * reference material for internal teams * explanatory documentation for clients It defines the standard approach to checkpoint design in Didge. --- # 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/checkpoints/about-settings.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.