> 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/packages-by-operations.md). # Packages by Operations Designing and Defining Operational Packages in Didge *** ### Purpose of This Page This page explains what an Operational Package is in Didge, the philosophy behind operational packaging, and how to design and define Operational Packages correctly. It is intended for: * internal teams (product, engineering, implementation, sales) * solution designers and partners * clients who want to understand how Didge can be deployed for specific operational contexts This page focuses only on Operational Packages. Functional (domain-based) Packages and Checkpoints are covered in separate documentation. *** ### What Is an Operational Package? In Didge, an Operational Package represents a holistic, operation-focused grouping of controls designed to support how a specific type of operation actually runs day to day. Operational Packages answer the question: > “What does this operation need to do to operate safely, compliantly, and effectively?” They are designed around real-world operational contexts, not around individual functional domains. *** ### How Operational Packages Differ from Functional Packages Understanding this distinction is critical. #### Functional Packages * Grouped by function or subject-matter domain * Define what capabilities exist in the platform * Examples: Supplier Management, Cold Chain, Cleaning & Sanitation * Form the architectural backbone of Didge #### Operational Packages * Grouped by type of operation or deployment context * Define how capabilities are combined and used * Examples: Small Commercial Kitchen, Aged Care Kitchen, Halal Kitchen * Provide ready-to-use, holistic solutions > Functional Packages define the building blocks. > Operational Packages define how those blocks are assembled for a real operation. *** ### Why Operational Packages Exist Many operations do not think in functional domains. They think in terms of: * “What do we need to do each day?” * “What does compliance look like for *this* kitchen?” * “What is the minimum set of controls we must run?”
Operational Packages exist to: * reduce configuration complexity * provide fast, sensible starting points * ensure nothing critical is missed * support consistent deployments across sites *** ### Operational Packages as Deployment Units Operational Packages are often used as deployment or rollout units. They allow: * rapid setup of new sites * consistent configuration across similar operations * alignment to regulatory or organisational standards They are especially useful in: * multi-site businesses * large organisations with varied operations * regulated environments *** ### What an Operational Package Contains An Operational Package: * includes checkpoints drawn from multiple Functional Packages * selects only the relevant depth of each capability * focuses on practical, day-to-day execution
Operational Packages: * do not introduce new functional logic * do not replace Functional Packages * do not redefine checkpoints
They are compositions, not new capabilities. *** ### Example: Small Commercial Kitchen A *Small Commercial Kitchen* Operational Package may include: From Incoming Goods (Functional Package): * basic delivery checks From Cold Chain Management: * fridge and freezer temperature monitoring From Cooking & Thermal Control: * core cooking and reheating checks From Cleaning & Sanitation: * daily and weekly cleaning schedules From Verification & Review: * basic verification and sign-off Together, these checkpoints create a complete operational solution for a small kitchen. *** ### Example: Small Kitchen Within a Hotel A small kitchen within a larger hotel may: * not manage its own suppliers * rely on central procurement Its Operational Package may therefore: * exclude supplier management checkpoints * include incoming goods, cooking, cleaning, and verification The same Functional Packages exist in the system, but the operational grouping differs. *** ### Example: Aged Care Food Service An *Aged Care Food Service* Operational Package may emphasise: * stricter temperature controls * additional verification and review * specific cleaning and hygiene requirements It may draw from the same Functional Packages as a restaurant, but with: * different checkpoint selection * different frequencies * different evidence requirements *** ### Example: Halal Kitchen Operations A *Halal Kitchen* Operational Package may include: * standard food safety controls * additional certification and verification checkpoints * segregation and handling controls These checkpoints are composed to meet a specific operational and regulatory context. *** ### Levels of Sophistication Within Operational Packages Operational Packages must support different levels of maturity. For example: * a small site may use minimal checkpoints * a larger or regulated site may enable additional controls This variation is achieved through: * checkpoint selection * configuration and frequency It does not require creating new Functional Packages. *** ### Relationship to Functional Packages, Checkpoints, and Forms Operational Packages: * sit above Functional Packages * assemble checkpoints from multiple domains Functional Packages: * define the available capabilities Checkpoints: * define specific operational controls Forms: * capture data for checkpoints This layered model ensures clarity and reuse. *** ### How to Design a New Operational Package When designing an Operational Package: 1. Identify the type of operation (e.g. café, hotel kitchen, aged care) 2. Define the operational outcome (e.g. baseline compliance, regulated care) 3. Identify the minimum required controls 4. Select appropriate checkpoints from Functional Packages 5. Validate the package against real operational workflows Operational Packages should feel complete but not excessive. *** ### Key Design Rules * Operational Packages are compositions, not new features * They should remain easy to understand * If complexity increases, it should be added at the checkpoint level * Functional Packages should never be duplicated *** ### One-Page Summary > Functional Packages define *what capabilities exist* > Operational Packages define *how those capabilities are used in practice* > Checkpoints provide the execution layer > Forms support data capture *** ### Intended Use This page should be used as: * guidance for designing Operational Packages * reference material for internal teams * supporting documentation for client discussions It establishes the standard approach to operational packaging 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/packages-by-operations.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.