Training Guide
Designing Reusable Forms via Packages and Checkpoints
Purpose of This Document
This guide explains how to design new functionality in Didge using the correct order of thinking:
Package → Checkpoint → Form
It is intended for:
internal teams (product, engineering, implementation, QA)
solution designers and partners
clients who want to understand how Didge solutions are structured
This is a design and decision-making guide, not a configuration manual.
The Core Principle
Didge is designed from customer needs backwards.
This means:
Packages represent what customers need at a business level
Checkpoints represent the operational controls required
Forms are reusable instruments used to capture data
When this order is followed, the platform stays flexible, scalable, and easy to maintain.
Why This Matters
Many systems fail because they:
design forms first and hard-code meaning into them
create duplicate forms for similar use cases
fragment logic across features
Didge avoids this by:
anchoring design in packages
defining intent at the checkpoint level
evolving forms only when reuse is proven
Starting Point: Always Begin with a Package
When designing new functionality, the first question is not about forms.
The first question is:
What business area or outcome does the customer need?
This is always answered by a Package, usually By Function.
Example Package: Supplier Management
Supplier Management represents a clear business need:
managing suppliers
ensuring suppliers remain compliant
maintaining required evidence
This package defines the scope and boundaries of what belongs inside it.
Step 1: Define Checkpoints Within the Package
Once the package is agreed, define the checkpoints that support it.
A checkpoint represents a specific control intent.
Each checkpoint should be described in plain language before any technical work begins.
Example Checkpoint: Supplier Certification Currency
Purpose
Ensure suppliers maintain valid, current certifications required for approval.
Control intent
a supplier must provide a certificate
the certificate has a validity or review date
the certificate must be renewed before expiry
Outcome
valid → supplier remains approved
expired → action required
At this stage:
no forms are designed
no fields are defined
no UI decisions are made
This is intentional.
Step 2: Design the Minimum Honest Form
Only after checkpoint intent is clear do we design a form.
The goal is to create the smallest, most neutral form that can support the checkpoint.
Example Form: Credential Record
This form is intentionally generic and reusable.
Typical fields
credential name or type
issuing body
document upload
valid from (optional)
valid until / review date
notes (optional)
Important rules:
the form does not decide what expiry means
the form does not enforce business rules
the form does not belong to one package
The form simply captures data.
Step 3: Attach Behaviour at the Checkpoint Level
All logic and behaviour belongs to the checkpoint, not the form.
For example, the Supplier Certification checkpoint defines:
which credential types are acceptable
what happens when a credential expires
when reminders are triggered
how supplier status is affected
This separation is what allows the same form to be reused elsewhere.
Step 4: Implement Fully for One Use Case First
It is correct to:
implement the full flow for one package
validate it in a real operational context
avoid premature generalisation
The key constraint is:
Do not rename or over-specialise the form.
Let reuse emerge naturally.
Step 5: Reuse the Pattern Across Other Packages
Once implemented, the same pattern can be reused in other areas.
Examples:
Staff training certificates
RSA or RSG currency
Food Safety Supervisor certificates
Licences and permits
All of these use:
different checkpoints
different rules and consequences
the same underlying form
When to Evolve a Form (Critical Rule)
Forms should only be extended when:
Multiple checkpoints require the same new data or capability.
Do not evolve a form:
for a single edge case
for one package only
to shortcut checkpoint logic
This keeps the form library stable and reusable.
How Forms Safely Evolve Over Time
As reuse increases, a form may be extended carefully.
For example:
adding a review date alongside expiry date
supporting non-expiring credentials
linking a credential to a person or organisation
These changes are:
additive
optional
backwards compatible
The form remains neutral.
One Canonical Pattern: Time-Bound Evidence
Internally, this pattern can be thought of as
Credential or Evidence with a Validity Period
It applies across many packages and industries.
Recognising these patterns early helps avoid duplication and redesign.
One-Page Summary
Start with the package (customer need)
Define checkpoints (control intent)
Design the smallest honest form
Attach behaviour at the checkpoint
Reuse and evolve forms only under pressure
Intended Use
This guide should be used:
as internal training material
during solution and feature design discussions
as explanatory material for advanced clients
It represents the standard approach for designing reusable, scalable functionality in Didge.
Last updated
Was this helpful?