> 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-function.md).
# Packages by Function
Designing and Defining Functional Packages in Didge
***
### Purpose of This Page
This page explains what a Functional Package is in Didge, the philosophy behind functional (domain-based) packaging, and how to design and define a functional package correctly.
It is intended for:
* internal teams (product, engineering, implementation, sales)
* solution designers and partners
* advanced clients who want to understand how Didge is structured
This page focuses only on Functional Packages.
Detailed design of checkpoints and forms is covered in separate documentation.
***
### What Is a Functional Package?
> Functional Packages group capabilities by functional or subject-matter domain.
> In Didge, the term *functional* is used to describe packages that are domain-based (for example Supplier Management, Cold Chain, Cleaning), rather than packages organised by type of operation.
> Functional Packages differ from Operational Packages, which are defined by how capabilities are combined for a specific operational context (for example a café, hotel kitchen, or airline catering environment).
> Domain Packages are defined by function or subject-matter.
> They differ from Operational Packages, which are defined by the type of operation (for example, a café, hotel kitchen, or airline catering environment).
In Didge, a Functional Package represents a business-level application focused on a specific functional or subject-matter domain (such as suppliers, cold chain, cleaning, or audits).
A package:
* addresses a clear business problem
* delivers a defined business outcome
* groups together multiple functional capabilities (checkpoints)
* can be implemented at different levels of sophistication
> A package explains why a system exists, not how every part works.
***
### Functional Packages Are Not Features or Bundles
A package is not:
* a pricing tier
* a simple feature list
* a checklist bundle
* a single workflow
Instead, a package should be thought of as:
> A cohesive operational application that supports decision-making, compliance, and risk control in one area of the business.
This distinction is critical for scale and clarity.
***
### Functional Packages as Business Applications
Each package in Didge should be understandable to a business user without technical explanation.
For example:
* *Supplier Management* is an application for managing supplier risk and compliance
* *Cold Chain Management* is an application for managing temperature control and food safety
* *Audit Management* is an application for managing verification and assurance activities
Packages define scope and intent, not implementation detail.
***
### The Role of Functional Packages in the Platform
Functional Packages are the primary organisational layer of Didge when defining functional capability:
* they are how customers understand the platform
* they are how solutions are marketed and sold
* they define implementation boundaries
* they anchor roadmap and prioritisation decisions
Packages intentionally sit above checkpoints and forms.
***
### What Information Is Required to Define a Functional Package
Every package should be defined using a consistent set of information.
#### 1. Package Name
The name should:
* reflect a clear business domain
* use language familiar to the industry
* avoid technical or implementation terms
Examples:
* Supplier Management
* Cold Chain Management
* Cleaning & Sanitation
* Audit & Verification
* HACCP Documentation & Governance
***
#### 2. Business Purpose
A short statement describing why this package exists.
This should answer:
> “What business problem does this package solve?”
Example:
> *Enable organisations to manage supplier compliance, approvals, and ongoing risk.*
***
#### 3. Business Outcome
Describe the end state the customer should achieve by using the package.
Outcomes should be expressed in business terms, not features.
Example outcomes:
* suppliers are approved, compliant, and monitored
* temperature risks are controlled and visible
* cleaning standards are consistently met
* audits are structured, repeatable, and defensible
***
#### 4. Scope and Boundaries
Clearly define what belongs inside the package and what does not.
This prevents overlap and uncontrolled growth.
Example:
* Supplier Management includes certification, approval, audits, and performance
* It does not include internal staff training or asset maintenance
***
#### 5. Typical Users
Identify who primarily interacts with the package:
* operational staff
* supervisors
* quality / compliance teams
* management
This helps guide usability and depth.
***
#### 6. Regulatory or Standards Context (If Applicable)
If relevant, note the regulatory or standards environment the package supports.
This should remain high-level.
Examples:
* food safety regulations
* HACCP principles
* internal governance requirements
Detailed regulatory mapping belongs at the checkpoint level.
***
### Functional Packages and Levels of Sophistication
A single package must support different levels of maturity.
For example:
* a small operation may use a limited subset of capabilities
* a large organisation may use the full breadth of controls
This variation is achieved by:
* enabling or disabling checkpoints
* configuring depth and rules
It should never require creating a new package.
***
### Examples of Well-Defined Functional Packages
#### Supplier Management
Purpose:
Manage supplier compliance, approvals, and risk.
Outcome:
Suppliers are approved, monitored, and suitable for use.
Scope includes:
* supplier certification management
* approval workflows
* supplier audits
* supplier performance and risk indicators
***
#### Cold Chain Management
Purpose:
Ensure temperature control across storage, handling, and transport.
Outcome:
Temperature risks are controlled, visible, and auditable.
Scope includes:
* cold and frozen storage monitoring
* alerts and corrective actions
* verification and review
***
#### Audit & Verification
Purpose:
Provide structured assurance that controls are working as intended.
Outcome:
Audits are consistent, repeatable, and defensible.
Scope includes:
* internal audits
* site inspections
* verification activities
* findings and corrective actions
***
#### HACCP Documentation & Governance
Purpose:
Manage food safety documentation and governance requirements.
Outcome:
Policies, procedures, and plans are current, controlled, and accessible.
Scope includes:
* HACCP plans
* policies and procedures
* document control and review
***
#### Cleaning & Sanitation
Purpose:
Ensure hygienic conditions and GMP compliance.
Outcome:
Cleaning activities are completed, verified, and effective.
Scope includes:
* routine cleaning
* deep cleaning
* verification and review
***
### Relationship Between Functional Packages, Checkpoints, and Forms
Packages:
* define what area of the business is being addressed
* group together multiple checkpoints
Checkpoints:
* define specific functional capabilities within a package
* contain operational logic and rules
Forms:
* are used by checkpoints to capture data
* do not define business meaning
This separation keeps packages understandable and scalable.
***
### How to Design a New Functional Package (Summary Process)
1. Identify the business problem or operational area
2. Define the business outcome
3. Set clear scope and boundaries
4. Identify the functional capabilities required (checkpoints)
5. Validate that the package can scale across different business sizes
Only after this process should checkpoint and form design begin.
***
### Key Rule to Remember
> If a description becomes too detailed or technical, it does not belong at the package level.
Packages stay outcome-focused.
Checkpoints carry the complexity.
***
### Intended Use
This page should be used as:
* the primary reference for defining packages in Didge
* onboarding material for internal teams
* explanatory documentation for clients
It establishes the standard approach to package design within 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-function.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.