> 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/get-started/procedure.md). # Procedure Designing, Configuring, Testing, and Releasing Functionality in Didge ### Purpose of this SOP This Standard Operating Procedure (SOP) defines the end-to-end, repeatable process for designing, configuring, validating, and releasing new functionality in Didge using the: Package → Checkpoint → Data Acquisition → Form framework. It ensures that: * business intent is clearly defined * real-world user behaviour is respected * existing Didge platform capabilities are leveraged first * configuration is testable and auditable * quality and consistency are maintained across deployments This SOP is mandatory for: * product and domain leads * subject matter experts (SMEs) * implementation and solution design teams * engineers and QA *** ### Scope This SOP applies to: * Functional Packages * Operational Packages * Form-based Checkpoints * Data Acquisition Scenarios * Configuration-driven delivery using Didge This SOP does not apply to: * core IoT / telemetry subsystems * cook–chill automation workflows *** ### Roles & Responsibilities | Role | Primary Responsibility | | ----------------------- | ----------------------------------------------------- | | SME / Product Authority | Defines package intent, outcomes, and normative rules | | Package Owner | Owns package definition and scope | | Solution Designer | Maps behaviour to Didge capabilities | | Implementation Team | Configures Didge features and forms | | QA | Validates behaviour against documentation | | Delivery Lead | Approves release readiness | *** ### Phase 1 – Package Definition (Intent) #### Objective Define what business outcome is required. #### Activities * Identify whether the package is: * Functional (by domain) * Operational (by operation) * Document: * business problem * intended outcomes * scope and non-goals * regulatory or standards context * List candidate checkpoints by name only #### Deliverables * Package Definition Brief #### Exit Criteria * Intent and scope approved by SME * No implementation detail included *** ### Phase 2 – Capability Rinse (Platform Fit Check) #### Objective Confirm how much of the package can be delivered using existing Didge capabilities. #### Activities * Review Didge platform features * Classify requirements as: * covered out-of-the-box * covered via configuration * requiring extension (if any) #### Deliverables * Capability Rinse Notes (internal) #### Exit Criteria * No unnecessary documentation of existing features * Agreement on configuration-first approach *** ### Phase 3 – Checkpoint Design (Control Definition) #### Objective Define what controls must exist and how correctness is enforced. #### Activities For each checkpoint: * Complete the Checkpoint Definition Template * Define: * control purpose * normative (standards-based) rules * contextual configuration options * pass/fail logic * exclusions #### Deliverables * Completed Checkpoint Definitions #### Exit Criteria * SME sign-off on control intent * Behaviour defined without referencing forms *** ### Phase 4 – Data Acquisition Design (Behaviour) #### Objective Define how data enters the system in real operational conditions. #### Activities For each checkpoint: * Identify one or more Data Acquisition Scenarios * Complete a Data Acquisition Behaviour Sheet per scenario * Define: * required human behaviour * supported acquisition methods (image, manual, post-event) * validation and guardrails * fallback paths * system preconditions #### Deliverables * Data Acquisition Behaviour Sheets #### Exit Criteria * Behaviour aligns with real operations * Manual and post-event capture supported where required * QA scenarios clearly testable *** ### Phase 5 – Form Design or Selection (Data Capture) #### Objective Enable data capture that supports defined behaviour and controls. #### Activities * Select existing forms where possible * Design new forms only if required * Ensure forms: * remain neutral and reusable * expose required configuration parameters * support defined data acquisition scenarios #### Deliverables * Form specifications or updated forms #### Exit Criteria * No business logic embedded in forms * Forms validated against acquisition scenarios *** ### Phase 6 – Configuration & Assembly #### Objective Configure Didge to realise the package design. #### Activities * Configure checkpoints using forms and settings * Apply normative defaults * Pre-configure contextual settings at package level * Assemble Functional and Operational Packages #### Deliverables * Configured packages in Didge #### Exit Criteria * Configuration matches documented behaviour * No site-level invention required *** ### Phase 7 – Testing & Quality Assurance #### Objective Validate that the system behaves as designed. #### Activities * Test each Data Acquisition Scenario end-to-end * Validate: * required inputs * validation rules * fallback behaviour * analytics outputs * Perform regression testing #### Deliverables * QA sign-off #### Exit Criteria * All scenarios pass * No critical defects outstanding *** ### Phase 8 – Implementation Validation #### Objective Confirm deployability in real environments. #### Activities * Deploy to pilot site * Confirm: * onboarding clarity * operational usability * configuration completeness #### Deliverables * Implementation sign-off *** ### Phase 9 – Release & Documentation #### Objective Release safely and preserve knowledge. #### Activities * Finalise Docs: * package overview * checkpoint references * acquisition scenarios * Version the release * Communicate internally #### Deliverables * Released package * Updated documentation *** ### Phase 10 – Post-Release Review #### Objective Capture learnings and improvements #### Activities * Gather feedback * Review behaviour vs intent * Log enhancements *** ### Quality Gates Summary | Phase | Gate | | ------------------ | --------------------- | | Package Definition | Intent approved | | Checkpoint Design | SME sign-off | | Data Acquisition | Behaviour validated | | Configuration | Matches documentation | | QA | All scenarios pass | | Release | Docs complete | *** ### Non-Negotiable Rules * Never design forms before data acquisition * Never assume real-time capture is always possible * Never embed logic in forms * Always support operational fallback paths * Always test behaviour, not just configuration *** ### Intended Use This SOP is the authoritative procedure for delivering functionality in Didge. All teams must follow this process for new packages, checkpoints, or major changes. --- # 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/get-started/procedure.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.