Designing Packages
Designing Packages, Checkpoints, and Forms in Didge
This document explains how solutions are designed in Didge, using a clear and repeatable hierarchy:
Package → Checkpoint → Form
It is intended for:
clients configuring or extending their Didge system
partners and implementers
internal teams (product, engineering, sales)
This document focuses on design intent, not pricing or licensing.
The Core Design Principle
Didge is designed from the customer outcome backwards.
This means:
Packages define what the customer needs
Checkpoints define what controls are required
Forms define how data is captured
Each layer depends on the one above it.
1. Packages
What is a Package?
A package represents a major area of business control or operation.
Packages answer the question:
“What area of my operation do I need to manage?”
Packages are what customers recognise and select.
Packages by Function
Didge primarily designs packages by function (subject-matter area).
Examples include:
Calibration & Verification
Cold Storage Control
Cleaning & Sanitation
Incoming Goods Control
Cooking & Thermal Process Control
Each package:
represents a clear business outcome
defines the scope and boundaries of that outcome
can be implemented at different levels of depth
Why Design Starts with Packages
Starting with packages ensures that:
the system is aligned to real customer needs
solutions are outcome-focused, not feature-driven
complexity is controlled at the highest level
Packages define the promise Didge makes to the customer.
2. Checkpoints
What is a Checkpoint?
A checkpoint is a specific operational control within a package.
Checkpoints answer the question:
“What specific check or control must occur to support this package?”
A package contains one or more checkpoints.
What a Checkpoint Defines
Each checkpoint defines:
the purpose of the control
who performs it
how often it occurs
what constitutes pass or fail
what happens if it fails
what evidence is required
This is where business logic and operational meaning live.
Example: Calibration Package
Package: Calibration & Verification
Example checkpoints:
Boil & Ice Point Calibration
Digital Sensor Calibration
Scale Calibration
External Certificate Verification
Each checkpoint represents a distinct control intent, even if they use similar data.
Why Checkpoints Come After Packages
Packages are too broad to design data capture directly.
Checkpoints provide:
clarity of purpose
operational boundaries
correct level of detail
Without checkpoints, forms become overly specific or overly generic.
3. Forms
What is a Form?
A form is a reusable data capture instrument.
Forms answer the question:
“How is the information for this checkpoint recorded?”
Forms are intentionally generic.
What Forms Define
A form defines:
fields (numbers, text, photos, signatures)
validation rules
layout and flow
data structure
Forms do not define business meaning.
Form Reuse in Didge
The same form may be used by multiple checkpoints and packages.
For example:
one temperature form may support fridge checks, freezer checks, and delivery checks
one checklist form may support cleaning, maintenance, or verification activities
Meaning is always supplied by the checkpoint, not the form.
The Design Flow
Define the package
(What business outcome is required?)
Define checkpoints within the package
(What specific controls are needed?)
Select or design forms to support checkpoints
(What data needs to be captured?)
This flow applies whether designing:
a new package
a new checkpoint
a new form
Minimal and Advanced Implementations
A package may be implemented at different levels of depth.
For example:
a small operation may use one or two simple checkpoints
a larger operation may enable many checkpoints with additional rules and evidence
This does not require new packages or new forms — only deeper checkpoint configuration.
Why This Matters
Designing in this order ensures that Didge:
remains simple for small operations
scales cleanly for complex environments
avoids duplicated or hard-coded forms
preserves data consistency over time
This structure allows Didge to grow without requiring rebuilds or migrations.
One-Page Summary
Packages define outcomes
Checkpoints define controls
Forms capture data
Always design in this order.
Intended Use
This document should be used as:
a reference on the Didge Docs site
guidance for solution design discussions
a shared language between Didge and its customers
Last updated
Was this helpful?