> 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/model.md). # Model *** ### Purpose of This Document This document defines the Checkpoint Settings Model used in Didge. It explains: * how checkpoint settings are structured * where different types of configuration belong * how forms, checkpoints, packages, and implementations interact This is a design and governance standard, intended for: * internal product and engineering teams * implementation and solution design teams * advanced partners and enterprise clients This document does not describe UI screens or step-by-step configuration. It defines the conceptual model that the platform follows. *** ### Why a Checkpoint Settings Model Is Required In Didge, checkpoints transform reusable forms into business-specific controls. Without a clear settings model: * configuration becomes inconsistent * implementation teams are forced to guess * regulatory knowledge is repeatedly reinterpreted * reuse breaks down The Checkpoint Settings Model ensures that: * professional knowledge is embedded once * configuration is guided and repeatable * flexibility exists without loss of control *** ### The Role of the Checkpoint A checkpoint sits between packages and forms. * Packages define *why* a control exists * Forms define *how* data is captured * Checkpoints define *what the control does and how it behaves* Checkpoint settings are the mechanism by which this behaviour is defined. *** ### The Three Categories of Checkpoint Settings All checkpoint settings fall into three distinct categories. These categories define: * where knowledge comes from * when it is defined * who is responsible for it *** #### 1. Normative Settings (Standards-Based) What they are Normative settings represent what should be true according to: * regulations * industry standards * accepted best practice They define the *baseline safety and compliance rules*. Examples * maximum cold storage temperature * minimum cooking temperature * requirement for certificate currency * mandatory corrective action on failure Characteristics * derived from subject-matter expertise * rarely changed * should have strong defaults * may be locked or constrained Defined by * product and subject-matter experts Stored at * checkpoint definition *** #### 2. Contextual Settings (Operational) What they are Contextual settings adapt a checkpoint to a specific operational context. They define *how the control is applied in practice*. Examples * frequency (daily, per shift, weekly) * tolerance ranges * required evidence * escalation rules * enabled or disabled form sections Characteristics * vary by operation or package * configurable within defined bounds * guided by operational expertise Defined by * solution designers * implementation leads Stored at * package-level checkpoint configuration *** #### 3. Instance Settings (Site-Specific) What they are Instance settings reflect real-world entities and conditions. They define *who or what the checkpoint applies to*. Examples * specific fridge or freezer * supplier or staff member * schedule or shift * site location Characteristics * always site-specific * never embedded in packages * frequently updated Defined by * site administrators * onboarding processes Stored at * site or asset level *** ### Summary Table | Setting Type | Purpose | Defined When | Owned By | Stored At | | ------------ | ---------------------------- | ----------------- | --------------- | ------------ | | Normative | Safety & compliance baseline | Checkpoint design | SME / Product | Checkpoint | | Contextual | Operational adaptation | Package design | Solution / Impl | Package | | Instance | Real-world application | Site deployment | Site Admin | Site / Asset | *** ### How Forms Support the Settings Model Forms do not own business logic. Instead, forms expose configurable parameters that checkpoints can control. At form design time, the form defines: * which parameters exist * allowed ranges or options * default values * whether parameters are overridable The form does not: * decide which values are correct * know whether a value is normative or contextual That meaning is applied at the checkpoint level. *** ### How Checkpoints Use Form Parameters When a form is configured as a checkpoint: * normative defaults may be applied * contextual values may be selected or adjusted * certain parameters may be locked or constrained This configuration is saved as part of the checkpoint definition. Once saved, the form + configuration together become a checkpoint. *** ### How Packages Interact with Checkpoint Settings Packages: * select which checkpoints are included * apply contextual configuration to checkpoints * predefine settings appropriate for the operational outcome Packages do not: * define normative rules * override regulatory baselines *** ### Implementation and Deployment During site deployment: * checkpoint definitions are applied as-is * instance data is supplied * no reinterpretation of rules occurs Implementation teams: * confirm applicability * adjust within allowed ranges * do not invent new critical values *** ### Key Design Rules * All business logic lives in checkpoints * Normative settings are defined once * Contextual settings are constrained * Instance settings are never hard-coded * Forms remain neutral and reusable *** ### One-Page Mental Model > Forms define what *can* be configured > Checkpoints define what *must* be configured > Packages define what *should* be pre-configured > Sites define what *is* configured *** ### Intended Use This document establishes the Checkpoint Settings Model as a standard for Didge. It should be used: * when designing new checkpoints * when refactoring forms * when building configuration UIs * when training implementation teams Adhering to this model ensures Didge remains scalable, consistent, and safe. --- # 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/model.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.