> 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/collections/introductions.md). # Introductions A Contextual Organisation Framework for Medium and Large-Scale Deployments ### 1. Overview As organisations expand their use of the Didge platform—adding more departments, more operational checkpoints, more procedures, and more compliance layers—the volume of content grows significantly. With growth comes complexity, and with complexity comes the need for structure. Collections are a new Didge feature designed specifically to meet this challenge. A Collection is a flexible grouping tool that allows you to categorise any part of the Didge platform by a subject, process, control, or standard. It functions conceptually like a tag or category, but is far more powerful: it can unify forms, checkpoints, submissions, policies, procedures, training materials, links, documents, and any supporting resources under a single context. Collections allow you to view the Didge platform from multiple architectural perspectives—not just operational—but also by food safety controls, program elements, and external standards such as HACCP, ISO 22000, BRC, SQF, and aviation catering frameworks. *** ### 2. The Operational Architecture The Didge platform has long been engineered around operational usability, designed with the chef, operator, or verifier as the primary stakeholder. #### 2.1 Work Areas as the Core Structure Work Areas are the foundation of the Didge operational model: * A Work Area typically represents a *kitchen*, *zone*, *department*, or *operational space*. * Each area contains only the operations relevant to that environment. * This configuration ensures simplicity and clarity for daily users. Example: A *Pastry Kitchen* may contain: * Cold storage checklist * Cleaning operations * Specific pastry production controls * Any verification tasks relevant to that kitchen A *Cold Kitchen* (Garde Manger) would contain *only* the processes relevant to cold production, goods receiving, or storage. #### 2.2 Why This Matters This operational-centric engineering aligns with: * Efficient team workflows * Clear separation of duties * Simple daily verification * Fast monitoring through scheduling and the Performance Report Didge’s architecture excels at: * Showing what must be done * Showing what has or hasn’t been done * Ensuring operations stay compliant This model has been validated over almost a decade of use in large-scale hospitality, foodservice, and institutional catering environments. *** ### 3. The Challenge: Non-Operational Perspective Auditors, hygiene managers, QA teams, and standards assessors often evaluate systems from a completely different perspective than operational staff. Where operations think in terms of: * Kitchens * Zones * Tasks * Daily verifications Auditors think in terms of: * Controls * Program elements * Sections of a food safety plan * Themes like cleaning, allergen management, supplier control, traceability, or training * Compliance clauses mapped to specific standards #### 3.1 Example: Supplier Management Operationally, supplier management spans multiple departments: * Procurement * Goods Receiving * Halal Receiving (if applicable) * Kitchens * QA * Admin or Purchasing Different parts of Didge relate to supplier management: * Approved supplier list * Incoming goods checklists * Halal receipt verification * Supplier audits * Complaint handling * Quarantine and rejection records * Policies and procedures * Training materials These resources live in different areas of the system—and rightly so. But when an auditor says: > “Show me everything related to supplier management,” …it becomes difficult to provide a consolidated single view. *** ### 4. How Collections Solve This Problem Collections provide a unified, contextual layer on top of the existing operational architecture. #### 4.1 Creating a Collection For the example above, you might create a Collection called: “Supplier Management” #### 4.2 Assigning Didge Resources You then assign any relevant resource to the Collection: * Approved Supplier Policy * Supplier Management Procedure * Incoming Goods Form * Halal Goods Receivable Form * Daily, weekly, or monthly submissions * Training modules * Vendor audit reports * Rejection logs and CAPAs * Any supporting documentation * Links, PDFs, reference files Once assigned, the Collection becomes the singular source of truth for that topic. #### 4.3 The Result Opening the “Supplier Management” Collection shows: * All forms tied to supplier control * All historical submissions * All policies and SOPs * All training documents * All related checkpoints * All associated reports and records In seconds, you can navigate what previously required multiple navigation paths. *** ### 5. Use Cases for Collections #### 5.1 Audits and Compliance Standards Collections can be aligned with the structure of any external audit framework: * HACCP plan sections * ISO 22000 clauses * BRC or SQF modules * Airline catering or GMP audit structures * Internal corporate standards * Ministry or regulatory requirements Creating Collections that mirror an auditor’s checklist allows QA teams to present the entire body of evidence without hunting through the operational layout. #### 5.2 Food Safety Program Elements Collections can represent: * Cleaning & Sanitation * Allergen Management * Cold Chain Control * Training & Competency * Calibration * Traceability * Pest Control * Waste Management Each Collection becomes a curated bundle of everything related to that program area. #### 5.3 Cross-Departmental Controls Many controls touch multiple departments. Collections finally allow those to be viewed holistically. #### 5.4 Large Multi-Year, Multi-Solution Builds Some Didge clients grow year after year, adding: * New workflows * New departments * Non-food-safety modules * Additional compliance areas Collections allow all of these to be tied together meaningfully—even when operational teams remain separated. *** ### 6. Why This Is Powerful #### 6.1 Complements Operational Architecture Collections don’t replace the Work Area model—they enhance it. Operational users continue to see: * Only what they need * In their kitchen * In their workflow While management, auditors, and QA can access the system from a completely different perspective. #### 6.2 A Second, Configurable View of the System Didge now offers: 1. Operational View * Simple * Daily use * Work-area based 2. Contextual View (Collections) * Thematic * Audit-ready * Program-structure #### 6.3 Simplifies Compliance and Reporting Collections make it easy to: * Prepare for audits * Demonstrate compliance * Review critical program elements * Link evidence across departments * Provide clarity to non-operational stakeholders #### 6.4 Scales with Complexity The larger the operation, the more value Collections provide. *** ### 7. Conclusion Collections introduce a new dimension to how Didge can be understood, navigated, and managed. They preserve the strength of the existing operational architecture—built around real-world workflows—while providing a powerful overlay for auditors, QA teams, standard frameworks, and subject-matter-based navigation. For medium to large businesses, or any organisation whose Didge system spans multiple departments and program areas, Collections significantly enhance: * Organisational clarity * Compliance visibility * Audit efficiency * Long-term scalability They transform Didge from a purely operational tool into a platform that can be viewed contextually from any angle—meeting the needs of both frontline operators and high-level auditors. --- # 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/collections/introductions.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.