> For the complete documentation index, see [llms.txt](https://docs.didge.io/home/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.didge.io/home/checkpoint-structure/get-started/get-started.md).

# 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:

1. What should exist?

   (Business and product intent)
2. What control must exist?

   (Correctness, rules, and governance)
3. 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)

1. Define the Package (intent and scope)
2. Identify required Checkpoints
3. Complete the Checkpoint Definition for each
4. Design Data Acquisition Scenarios for each checkpoint
5. Design or reuse Forms
6. Configure checkpoints within packages
7. Assemble Operational Packages if required
8. 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<br>

It defines the official starting approach for building in Didge.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.didge.io/home/checkpoint-structure/get-started/get-started.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.