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)
Identify the business problem or operational area
Define the business outcome
Set clear scope and boundaries
Identify the functional capabilities required (checkpoints)
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.
Last updated
Was this helpful?