> 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/working-example.md). # Working Example Working Example: Supplier Management (End-to-End SOP) *** ### Purpose of This Document This document provides a complete, worked example of how to apply the Didge SOP for Designing, Building, Testing, and Releasing Packages, Checkpoints, and Forms. It is intended as: * a training reference for internal teams * a concrete example of the abstract framework * a model that can be copied for other packages This example follows the full process from Package → Checkpoints → Forms → Testing → Release. *** ### Scenario Overview Target Customer: Medium–large hotel Operational Context: * Central procurement * Multiple kitchens / outlets * HACCP-based food safety program Identified Business Problem: The hotel needs a structured, auditable way to manage supplier food safety risk, including approvals, certifications, incoming goods verification, and supplier-related corrective actions. *** ### Phase 1 – Package Definition (Intent) #### Package Type * ☑ Functional Package (by function / domain) #### Package Name Supplier Management #### Business Purpose Enable the organisation to manage supplier food safety risk, compliance, and traceability in line with HACCP principles. #### Business Outcome * Suppliers are approved before use * Supplier certifications are current and monitored * Goods are received safely and verified * Issues with suppliers are documented and acted upon * Supplier data is available for recalls and investigations #### Scope (In Scope) * approved supplier list * supplier profiles and contact details * supplier food safety certifications * vendor audits * incoming goods verification * supplier complaints and corrective actions #### Out of Scope * internal staff training * recipe management * IoT-based temperature telemetry #### Candidate Checkpoints (Names Only) * Supplier Profile * Supplier Certification Currency * Supplier Approval * Vendor Audit * Incoming Goods Verification * Supplier Complaint * Supplier Corrective Action *** ### Phase 2 – Checkpoint Design (Correctness) Below is a subset of checkpoint definitions to illustrate the process. *** #### Checkpoint 1: Supplier Profile Purpose Maintain a single, authoritative record for each supplier. Normative Settings * supplier must have a unique identifier * contact details required Contextual Settings * mandatory fields by organisation Instance Data * supplier name, address, contacts Primary Form Supplier Profile Form *** #### Checkpoint 2: Supplier Certification Currency Purpose Ensure suppliers maintain required food safety certifications. Normative Settings * certificate must be current * expiry date required Contextual Settings * certificate types required (e.g. HACCP, Halal) * reminder timing (e.g. 30 days before expiry) Instance Data * supplier * certificate documents Primary Form Document / Certificate Manager Form *** #### Checkpoint 3: Incoming Goods Verification Purpose Verify food is received safely and meets acceptance criteria. Normative Settings * temperature must meet food safety limits * damaged or unsafe goods must be rejected Contextual Settings * acceptance criteria by product type * mandatory photo capture for failures Instance Data * delivery * product * temperature Primary Form Incoming Goods Verification Form Vision AI Use * capture images of damaged packaging * detect visible contamination *** #### Checkpoint 4: Vendor Audit Purpose Assess supplier compliance beyond documentation. Normative Settings * audit must be completed before approval (where required) Contextual Settings * audit frequency * scoring thresholds Instance Data * supplier * audit responses Primary Form Supplier Audit Checklist Form *** ### Phase 3 – Form Design / Selection #### Forms Used | Form | Reuse Notes | | --------------------- | ---------------------------------------------- | | Supplier Profile Form | Reused for internal and external entities | | Document Manager Form | Used across certifications, licences, training | | Incoming Goods Form | Used in multiple packages | | Audit Checklist Form | Reused for site and supplier audits | All forms: * expose configurable parameters * remain neutral * contain no business logic *** ### Phase 4 – Checkpoint Configuration For each checkpoint: * normative defaults applied * contextual options configured at package level Example: * Incoming Goods Verification * temperature limits set * photo capture enabled on failure Configuration is saved with the Supplier Management package. *** ### Phase 5 – Package Assembly The Supplier Management Functional Package includes: * Supplier Profile * Supplier Certification Currency * Supplier Approval * Vendor Audit * Incoming Goods Verification * Supplier Complaint * Supplier Corrective Action An Operational Package (e.g. “Hotel Kitchen – Standard”) may include a subset of these checkpoints. *** ### Phase 6 – Testing & QA #### Functional Testing * supplier cannot be approved without valid certification * expired certificates trigger alerts #### Configuration Testing * certificate types vary by operation #### Reuse Testing * document form used for training certificates without conflict #### Vision AI Testing * images correctly attached to goods verification QA signs off once all tests pass. *** ### Phase 7 – Implementation Validation Test deployment to a hotel site: * suppliers created * certificates uploaded * deliveries recorded No new configuration required at site level. *** ### Phase 8 – Release & Documentation * package documented in Docs * checkpoint references linked * version released *** ### Phase 9 – Post-Release Review * feedback from pilot hotel * confirm usability and completeness * log enhancements *** ### Summary: What This Example Demonstrates * Packages define business intent * Checkpoints define controls * Forms enable reuse * Settings ensure governance * SOP ensures quality This Supplier Management example should be used as the reference implementation for future work. --- # 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/working-example.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.