Get Started
Where to Start: Designing Packages, Checkpoints, Data Acquisition and Forms in Didge
Purpose of This Guide
This guide explains where to start when designing new functionality in Didge using the:
Package → Checkpoint → Data Acquisition → Form framework.
It exists to remove a common point of confusion:
Do we start with packages, checkpoints, data acquisition, or forms?
The answer is not a single starting point, but a deliberate sequence that separates intent, behaviour, and construction.
This guide should be read by:
product and domain experts
engineers and form designers
implementation and solution design teams
partners building solutions on Didge
The Short Answer (Read This First)
You always start with a Package to define intent and scope.
You always start building with a Checkpoint to ensure correctness.
You must design Data Acquisition before designing forms.
These statements are not contradictory.
They describe different phases of work.
Why There Are Multiple Starting Points
Designing in Didge involves solving three different problems:
What should exist?
(Business and product intent)
What control must exist?
(Correctness, rules, and governance)
How does data actually enter the system?
(Human behaviour and operational reality)
These problems must be addressed in the correct order, but at different layers.
Phase 1 — Start with the Package (Intent and Scope)
You always begin by defining a Package.
Packages represent business-level applications and define:
the business problem being solved
the intended outcome
scope and boundaries
what is explicitly in and out of scope
At this stage:
you are not designing checkpoints
you are not designing data capture
you are not designing forms
you are not defining settings
You are answering:
“What does the business need?”
Example
We need a Supplier Management Functional Package.
At this point you define:
purpose: manage supplier risk and compliance
outcome: suppliers are approved and monitored
scope: certificates, audits, approvals
You may list candidate checkpoints by name only, but you do not design them yet.
Phase 2 — Design the Checkpoints (Correctness and Control)
Once the package intent is clear, all real construction starts at the checkpoint.
Checkpoints are where:
business logic lives
regulatory rules are encoded
control intent is defined
reuse is made safe
For each checkpoint, you must:
define its purpose
define normative (standards-based) settings
define contextual (operational) options
define pass/fail behaviour
This is where subject-matter and operational expertise is embedded.
Key Rule
If you cannot clearly define a checkpoint, you are not ready to design data acquisition or forms.
Phase 3 — Design Data Acquisition (Behaviour)
Once a checkpoint is defined, the next step is to design how data enters the system.
Data Acquisition focuses on real-world behaviour, not screens or forms.
It answers:
when data is captured
who captures it
what the person physically does
how technology supports that behaviour
what happens when capture is missed
For each checkpoint, define one or more Data Acquisition Scenarios that describe:
required human behaviour
supported acquisition methods (image-based, manual, post-event)
validation and guardrails
failure and fallback paths
This step ensures the system aligns with operational reality before forms are designed.
Key Rule
If you cannot describe how data is acquired in the real world, you are not ready to design a form.
Phase 4 — Design or Select Forms (Data Capture)
Forms are designed after checkpoints and data acquisition.
Forms:
capture data
expose configurable parameters
support defined data acquisition scenarios
remain neutral and reusable
Forms do not:
define business meaning
enforce compliance
decide behaviour
A form exists to serve a checkpoint and its data acquisition scenarios — never the other way around.
Phase 5 — Assemble Packages (Composition)
Once checkpoints and their data acquisition scenarios exist:
checkpoints are attached to Functional Packages
contextual settings are pre-configured
Operational Packages may be assembled
This phase is about composition, not invention.
Why Starting “in the Middle” Feels Wrong (But Isn’t)
It is common to feel unsure about “starting in the middle.”
This happens when:
checkpoints are designed without package intent, or
data capture is designed without understanding behaviour
The correct framing is:
Packages are the unit of intent
Checkpoints are the unit of control
Data Acquisition is the unit of behaviour
Forms are the unit of capture
You never design checkpoints without a package, and you never design forms without data acquisition.
What Not to Do
Avoid these common mistakes:
designing forms first
embedding logic in forms
designing data capture without understanding behaviour
defining package behaviour without checkpoints
asking implementation teams to invent critical values
If any of these occur, design clarity will break down.
End-to-End Design Flow (Summary)
Define the Package (intent and scope)
Identify required Checkpoints
Complete the Checkpoint Definition for each
Design Data Acquisition Scenarios for each checkpoint
Design or reuse Forms
Configure checkpoints within packages
Assemble Operational Packages if required
Deploy to sites with instance data
One-Page Mental Model
Packages define why
Checkpoints define what
Data Acquisition defines how behaviour happens
Forms define how data is captured
Intended Use
This guide should be used:
as onboarding material for new team members
as a reference when starting new work
to resolve design debates
It defines the official starting approach for building in Didge.
Last updated
Was this helpful?