> 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/definition-template.md). # Definition Template ### Purpose of This Template This template is used to define a checkpoint in Didge in a clear, consistent, and governed way. It ensures that: * business intent is explicit * regulatory and operational knowledge is captured once * configuration is predictable and reusable * forms remain neutral and reusable This template should be completed: * when creating a new checkpoint * when materially changing an existing checkpoint It is intended for: * product and domain experts * solution designers * implementation leads *** ### 1. Checkpoint Identity Checkpoint Name (Short, descriptive, action-oriented) > Example: *Daily Fridge Temperature Check* Checkpoint Category (Functional Package this checkpoint belongs to) > Example: *Cold Chain Management* Checkpoint Type (What kind of control this is) * ☐ Measurement * ☐ Verification * ☐ Checklist * ☐ Audit / Assessment * ☐ Evidence / Credential * ☐ Other: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ *** ### 2. Business Purpose & Outcome Purpose (Why does this checkpoint exist?) > Describe the risk or business problem this checkpoint controls. Intended Outcome > Describe the desired end state when this checkpoint is operating correctly. *** ### 3. Operational Context Who Performs This Checkpoint? * ☐ Operator * ☐ Supervisor * ☐ QA / Compliance * ☐ Manager * ☐ Other: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ When Does It Occur? > e.g. daily, per shift, per delivery, weekly, ad-hoc *** ### 4. Normative Settings (Standards-Based) These settings represent non-negotiable or recommended baseline rules derived from regulations or accepted best practice. Normative Requirements | Parameter | Description | Default | Allowed Range | Locked? | | --------- | ----------- | ------- | ------------- | ------- | | | | | | ☐ | | | | | | ☐ | Source / Rationale > Regulation, standard, guideline, or expert rationale. *** ### 5. Contextual Settings (Operationally Adjustable) These settings adapt the checkpoint to different operational environments. Configurable Parameters | Parameter | Description | Default | Allowed Options / Range | | --------- | ----------- | ------- | ----------------------- | | | | | | | | | | | Guidance Notes > Provide guidance to implementation teams on how and when these should be adjusted. *** ### 6. Instance Settings (Site-Specific Data) These settings are supplied during site deployment and are never preconfigured. Instance Data Required * ☐ Assets (e.g. fridge, freezer, equipment) * ☐ People (staff, suppliers) * ☐ Schedules / shifts * ☐ Locations * ☐ Other: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ *** ### 7. Form Association Primary Form Used > Name of reusable form Form Parameters Used | Parameter | Used by Checkpoint? | Notes | | --------- | ------------------- | ----- | | | ☐ | | | | ☐ | | Form Behaviour Notes > Any important notes about how the form is used in this checkpoint. *** ### 8. Pass / Fail Logic What Constitutes a Pass? > Describe conditions for success. What Constitutes a Fail? > Describe failure conditions. *** ### 9. Corrective Actions & Escalation Required Corrective Actions > What must happen when the checkpoint fails? Escalation Rules > Who is notified, when, and under what conditions. *** ### 10. Reporting & Review Key Metrics / Outputs > What this checkpoint contributes to reporting and dashboards. Review Frequency > How often the checkpoint configuration should be reviewed. *** ### 11. Package Usage Functional Packages > Which Functional Packages include this checkpoint. Operational Packages > Which Operational Packages typically use this checkpoint. *** ### 12. Versioning & Governance Version > e.g. v1.0 Owner > Role or team responsible for this checkpoint Last Reviewed > Date ### Design Validation Checklist Before approving this checkpoint definition, confirm: * ☐ Purpose and outcome are clear * ☐ Normative settings are defined and justified * ☐ Contextual settings are bounded and guided * ☐ Instance data is not hard-coded * ☐ Form remains reusable and neutral * ☐ No business logic is embedded in the form *** ### Notes > Additional design considerations or future enhancements. *** This template is the authoritative structure for defining checkpoints 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/definition-template.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.