Model
Purpose of This Document
This document defines the Checkpoint Settings Model used in Didge.
It explains:
how checkpoint settings are structured
where different types of configuration belong
how forms, checkpoints, packages, and implementations interact
This is a design and governance standard, intended for:
internal product and engineering teams
implementation and solution design teams
advanced partners and enterprise clients
This document does not describe UI screens or step-by-step configuration. It defines the conceptual model that the platform follows.
Why a Checkpoint Settings Model Is Required
In Didge, checkpoints transform reusable forms into business-specific controls.
Without a clear settings model:
configuration becomes inconsistent
implementation teams are forced to guess
regulatory knowledge is repeatedly reinterpreted
reuse breaks down
The Checkpoint Settings Model ensures that:
professional knowledge is embedded once
configuration is guided and repeatable
flexibility exists without loss of control
The Role of the Checkpoint
A checkpoint sits between packages and forms.
Packages define why a control exists
Forms define how data is captured
Checkpoints define what the control does and how it behaves
Checkpoint settings are the mechanism by which this behaviour is defined.
The Three Categories of Checkpoint Settings
All checkpoint settings fall into three distinct categories.
These categories define:
where knowledge comes from
when it is defined
who is responsible for it
1. Normative Settings (Standards-Based)
What they are
Normative settings represent what should be true according to:
regulations
industry standards
accepted best practice
They define the baseline safety and compliance rules.
Examples
maximum cold storage temperature
minimum cooking temperature
requirement for certificate currency
mandatory corrective action on failure
Characteristics
derived from subject-matter expertise
rarely changed
should have strong defaults
may be locked or constrained
Defined by
product and subject-matter experts
Stored at
checkpoint definition
2. Contextual Settings (Operational)
What they are
Contextual settings adapt a checkpoint to a specific operational context.
They define how the control is applied in practice.
Examples
frequency (daily, per shift, weekly)
tolerance ranges
required evidence
escalation rules
enabled or disabled form sections
Characteristics
vary by operation or package
configurable within defined bounds
guided by operational expertise
Defined by
solution designers
implementation leads
Stored at
package-level checkpoint configuration
3. Instance Settings (Site-Specific)
What they are
Instance settings reflect real-world entities and conditions.
They define who or what the checkpoint applies to.
Examples
specific fridge or freezer
supplier or staff member
schedule or shift
site location
Characteristics
always site-specific
never embedded in packages
frequently updated
Defined by
site administrators
onboarding processes
Stored at
site or asset level
Summary Table
Setting Type
Purpose
Defined When
Owned By
Stored At
Normative
Safety & compliance baseline
Checkpoint design
SME / Product
Checkpoint
Contextual
Operational adaptation
Package design
Solution / Impl
Package
Instance
Real-world application
Site deployment
Site Admin
Site / Asset
How Forms Support the Settings Model
Forms do not own business logic.
Instead, forms expose configurable parameters that checkpoints can control.
At form design time, the form defines:
which parameters exist
allowed ranges or options
default values
whether parameters are overridable
The form does not:
decide which values are correct
know whether a value is normative or contextual
That meaning is applied at the checkpoint level.
How Checkpoints Use Form Parameters
When a form is configured as a checkpoint:
normative defaults may be applied
contextual values may be selected or adjusted
certain parameters may be locked or constrained
This configuration is saved as part of the checkpoint definition.
Once saved, the form + configuration together become a checkpoint.
How Packages Interact with Checkpoint Settings
Packages:
select which checkpoints are included
apply contextual configuration to checkpoints
predefine settings appropriate for the operational outcome
Packages do not:
define normative rules
override regulatory baselines
Implementation and Deployment
During site deployment:
checkpoint definitions are applied as-is
instance data is supplied
no reinterpretation of rules occurs
Implementation teams:
confirm applicability
adjust within allowed ranges
do not invent new critical values
Key Design Rules
All business logic lives in checkpoints
Normative settings are defined once
Contextual settings are constrained
Instance settings are never hard-coded
Forms remain neutral and reusable
One-Page Mental Model
Forms define what can be configured
Checkpoints define what must be configured
Packages define what should be pre-configured
Sites define what is configured
Intended Use
This document establishes the Checkpoint Settings Model as a standard for Didge.
It should be used:
when designing new checkpoints
when refactoring forms
when building configuration UIs
when training implementation teams
Adhering to this model ensures Didge remains scalable, consistent, and safe.
Last updated
Was this helpful?