About Settings
Designing and Configuring Checkpoints in Didge
Purpose of This Page
This page explains what a Checkpoint is in Didge, how checkpoints sit between Packages and Forms, and how checkpoints are created by configuring forms.
It is intended for:
internal teams (product, engineering, implementation, QA)
solution designers and partners
clients who want to understand how Didge turns forms into real business controls
This page focuses on checkpoints and their relationship to forms and packages.
What Is a Checkpoint?
In Didge, a Checkpoint is a configured instance of a form that has been given business context.
A checkpoint exists when:
a form has been selected
configuration has been applied
business rules have been defined
A form becomes a checkpoint only after it is configured.
Until configuration occurs, a form is just a reusable instrument.
The Role of Checkpoints in the Didge Model
Checkpoints sit at the centre of the Didge framework:
Packages define why controls are needed
Checkpoints define what specific control exists
Forms define how data is captured
Checkpoints are where:
business meaning is applied
operational behaviour is defined
reuse becomes safe and scalable
Checkpoints as the Execution Layer
A checkpoint represents a real-world action or control such as:
recording a temperature
verifying a delivery
completing a cleaning task
confirming a certificate is current
Checkpoints are what operators actually interact with.
How Forms Become Checkpoints
Forms in Didge are deliberately designed to be:
reusable
neutral
context-free
A form becomes a checkpoint when it is assigned to a package and configured.
This configuration step is essential.
Checkpoint Configuration (Admin Perspective)
When a form is added to a package, the administrator is presented with a Checkpoint Settings area.
This is where the form is transformed into a business-specific control.
Typical configuration includes:
naming the checkpoint
adding instructional content or checklist text
enabling or disabling sections of the form
defining required vs optional fields
setting frequencies or schedules
defining pass/fail logic
setting critical limits or thresholds
configuring regional or regulatory variations
Once saved, this configuration defines the checkpoint.
Configuration Is Stored with the Checkpoint
Checkpoint configuration is:
saved at the package level
versioned as part of the package definition
reused consistently wherever the package is deployed
This ensures:
consistent behaviour across sites
predictable implementation
reduced configuration effort during rollout
From Package to Implementation
The lifecycle of a checkpoint is:
A Form is selected
The form is configured within a package
The configuration is saved as a checkpoint definition
The package is deployed to a site
The checkpoint appears with its predefined behaviour
At deployment time:
no additional configuration is required
the checkpoint behaves exactly as defined
Example: Temperature Checkpoint
Form: Generic Temperature Entry Form
Configured as a Checkpoint: Daily Fridge Temperature Check
Configuration may include:
acceptable temperature range (e.g. ≤ 5°C)
required frequency (daily)
mandatory corrective action on failure
instructional text for staff
The same form could also be configured as:
Incoming Goods Temperature Check
Freezer Temperature Check
Each is a different checkpoint with different settings.
Example: Certificate Currency Checkpoint
Form: Credential Record Form
Configured as a Checkpoint: Supplier Certificate Currency Check
Configuration may include:
required certificate types
expiry or review date rules
reminder timing
consequences of expiry
The same form could be reused for:
staff training currency
licence or permit review
Why Configuration Belongs at the Checkpoint Level
Placing configuration at the checkpoint level ensures:
forms remain reusable
packages remain understandable
business logic is not duplicated
It prevents:
form sprawl
hard-coded rules
inconsistent behaviour across sites
Checkpoints and Package Sophistication
A package may include:
a small number of simple checkpoints, or
a large number of complex checkpoints
Sophistication is achieved by:
adding more checkpoints
increasing configuration depth
Not by creating new forms or packages unnecessarily.
Relationship to Functional and Operational Packages
Checkpoints:
are defined within Functional Packages
are composed into Operational Packages
The same checkpoint definition may be used:
across multiple operational contexts
at different sites
This ensures consistency without rigidity.
Key Design Rules for Checkpoints
A form is not a checkpoint until it is configured
All business logic belongs to the checkpoint
Forms must remain neutral and reusable
Configuration should be saved once and reused
If logic feels too complex for a package, it belongs in a checkpoint
One-Page Summary
Packages define why
Checkpoints define what and how
Forms capture data
A checkpoint is created by configuring a form within a package.
Intended Use
This page should be used as:
guidance for designing checkpoints
reference material for internal teams
explanatory documentation for clients
It defines the standard approach to checkpoint design in Didge.
Last updated
Was this helpful?