Definition Template

Purpose of This Template

This template is used to define a checkpoint in Didge in a clear, consistent, and governed way.

It ensures that:

• business intent is explicit

• regulatory and operational knowledge is captured once

• configuration is predictable and reusable

• forms remain neutral and reusable

This template should be completed:

• when creating a new checkpoint

• when materially changing an existing checkpoint

It is intended for:

• product and domain experts

• solution designers

• implementation leads

---

1. Checkpoint Identity

Checkpoint Name

(Short, descriptive, action-oriented)

Example: Daily Fridge Temperature Check

Checkpoint Category

(Functional Package this checkpoint belongs to)

Example: Cold Chain Management

Checkpoint Type

(What kind of control this is)

• ☐ Measurement

• ☐ Verification

• ☐ Checklist

• ☐ Audit / Assessment

• ☐ Evidence / Credential

• ☐ Other: __________________

---

2. Business Purpose & Outcome

Purpose (Why does this checkpoint exist?)

Describe the risk or business problem this checkpoint controls.

Intended Outcome

Describe the desired end state when this checkpoint is operating correctly.

---

3. Operational Context

Who Performs This Checkpoint?

• ☐ Operator

• ☐ Supervisor

• ☐ QA / Compliance

• ☐ Manager

• ☐ Other: __________________

When Does It Occur?

e.g. daily, per shift, per delivery, weekly, ad-hoc

---

4. Normative Settings (Standards-Based)

These settings represent non-negotiable or recommended baseline rules derived from regulations or accepted best practice.

Normative Requirements

Parameter	Description	Default	Allowed Range	Locked?
				☐
				☐

Source / Rationale

Regulation, standard, guideline, or expert rationale.

---

5. Contextual Settings (Operationally Adjustable)

These settings adapt the checkpoint to different operational environments.

Configurable Parameters

Parameter	Description	Default	Allowed Options / Range

Guidance Notes

Provide guidance to implementation teams on how and when these should be adjusted.

---

6. Instance Settings (Site-Specific Data)

These settings are supplied during site deployment and are never preconfigured.

Instance Data Required

• ☐ Assets (e.g. fridge, freezer, equipment)

• ☐ People (staff, suppliers)

• ☐ Schedules / shifts

• ☐ Locations

• ☐ Other: __________________

---

7. Form Association

Primary Form Used

Name of reusable form

Form Parameters Used

Parameter	Used by Checkpoint?	Notes
	☐
	☐

Form Behaviour Notes

Any important notes about how the form is used in this checkpoint.

---

8. Pass / Fail Logic

What Constitutes a Pass?

Describe conditions for success.

What Constitutes a Fail?

Describe failure conditions.

---

9. Corrective Actions & Escalation

Required Corrective Actions

What must happen when the checkpoint fails?

Escalation Rules

Who is notified, when, and under what conditions.

---

10. Reporting & Review

Key Metrics / Outputs

What this checkpoint contributes to reporting and dashboards.

Review Frequency

How often the checkpoint configuration should be reviewed.

---

11. Package Usage

Functional Packages

Which Functional Packages include this checkpoint.

Operational Packages

Which Operational Packages typically use this checkpoint.

---

12. Versioning & Governance

Version

e.g. v1.0

Owner

Role or team responsible for this checkpoint

Last Reviewed

Date

Design Validation Checklist

Before approving this checkpoint definition, confirm:

• ☐ Purpose and outcome are clear

• ☐ Normative settings are defined and justified

• ☐ Contextual settings are bounded and guided

• ☐ Instance data is not hard-coded

• ☐ Form remains reusable and neutral

• ☐ No business logic is embedded in the form

---

Notes

Additional design considerations or future enhancements.

---

This template is the authoritative structure for defining checkpoints in Didge.