> 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/training-guide.md). # Training Guide Designing Reusable Forms via Packages and Checkpoints ### Purpose of This Document This guide explains how to design new functionality in Didge using the correct order of thinking: > Package → Checkpoint → Form It is intended for: * internal teams (product, engineering, implementation, QA) * solution designers and partners * clients who want to understand how Didge solutions are structured This is a design and decision-making guide, not a configuration manual. *** ### The Core Principle Didge is designed from customer needs backwards. This means: * Packages represent what customers need at a business level * Checkpoints represent the operational controls required * Forms are reusable instruments used to capture data When this order is followed, the platform stays flexible, scalable, and easy to maintain. *** ### Why This Matters Many systems fail because they: * design forms first and hard-code meaning into them * create duplicate forms for similar use cases * fragment logic across features Didge avoids this by: * anchoring design in packages * defining intent at the checkpoint level * evolving forms only when reuse is proven *** ### Starting Point: Always Begin with a Package When designing new functionality, the first question is not about forms. The first question is: > *What business area or outcome does the customer need?* This is always answered by a Package, usually By Function. *** #### Example Package: Supplier Management Supplier Management represents a clear business need: * managing suppliers * ensuring suppliers remain compliant * maintaining required evidence This package defines the scope and boundaries of what belongs inside it. *** ### Step 1: Define Checkpoints Within the Package Once the package is agreed, define the checkpoints that support it. A checkpoint represents a specific control intent. Each checkpoint should be described in plain language before any technical work begins. *** #### Example Checkpoint: Supplier Certification Currency Purpose Ensure suppliers maintain valid, current certifications required for approval. Control intent * a supplier must provide a certificate * the certificate has a validity or review date * the certificate must be renewed before expiry Outcome * valid → supplier remains approved * expired → action required At this stage: * no forms are designed * no fields are defined * no UI decisions are made This is intentional. *** ### Step 2: Design the Minimum Honest Form Only after checkpoint intent is clear do we design a form. The goal is to create the smallest, most neutral form that can support the checkpoint. *** #### Example Form: Credential Record This form is intentionally generic and reusable. Typical fields * credential name or type * issuing body * document upload * valid from (optional) * valid until / review date * notes (optional) Important rules: * the form does not decide what expiry means * the form does not enforce business rules * the form does not belong to one package The form simply captures data. *** ### Step 3: Attach Behaviour at the Checkpoint Level All logic and behaviour belongs to the checkpoint, not the form. For example, the Supplier Certification checkpoint defines: * which credential types are acceptable * what happens when a credential expires * when reminders are triggered * how supplier status is affected This separation is what allows the same form to be reused elsewhere. *** ### Step 4: Implement Fully for One Use Case First It is correct to: * implement the full flow for one package * validate it in a real operational context * avoid premature generalisation The key constraint is: > Do not rename or over-specialise the form. Let reuse emerge naturally. *** ### Step 5: Reuse the Pattern Across Other Packages Once implemented, the same pattern can be reused in other areas. Examples: * Staff training certificates * RSA or RSG currency * Food Safety Supervisor certificates * Licences and permits All of these use: * different checkpoints * different rules and consequences * the same underlying form *** ### When to Evolve a Form (Critical Rule) Forms should only be extended when: > Multiple checkpoints require the same new data or capability. Do not evolve a form: * for a single edge case * for one package only * to shortcut checkpoint logic This keeps the form library stable and reusable. *** ### How Forms Safely Evolve Over Time As reuse increases, a form may be extended carefully. For example: * adding a review date alongside expiry date * supporting non-expiring credentials * linking a credential to a person or organisation These changes are: * additive * optional * backwards compatible The form remains neutral. *** ### One Canonical Pattern: Time-Bound Evidence Internally, this pattern can be thought of as > Credential or Evidence with a Validity Period It applies across many packages and industries. Recognising these patterns early helps avoid duplication and redesign. *** ### One-Page Summary > Start with the package (customer need) > Define checkpoints (control intent) > Design the smallest honest form > Attach behaviour at the checkpoint > Reuse and evolve forms only under pressure *** ### Intended Use This guide should be used: * as internal training material * during solution and feature design discussions * as explanatory material for advanced clients It represents the standard approach for designing reusable, scalable functionality 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/packages/training-guide.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.