Procedure
Designing, Configuring, Testing, and Releasing Functionality in Didge
Purpose of this SOP
This Standard Operating Procedure (SOP) defines the end-to-end, repeatable process for designing, configuring, validating, and releasing new functionality in Didge using the:
Package → Checkpoint → Data Acquisition → Form framework.
It ensures that:
business intent is clearly defined
real-world user behaviour is respected
existing Didge platform capabilities are leveraged first
configuration is testable and auditable
quality and consistency are maintained across deployments
This SOP is mandatory for:
product and domain leads
subject matter experts (SMEs)
implementation and solution design teams
engineers and QA
Scope
This SOP applies to:
Functional Packages
Operational Packages
Form-based Checkpoints
Data Acquisition Scenarios
Configuration-driven delivery using Didge
This SOP does not apply to:
core IoT / telemetry subsystems
cook–chill automation workflows
Roles & Responsibilities
Role
Primary Responsibility
SME / Product Authority
Defines package intent, outcomes, and normative rules
Package Owner
Owns package definition and scope
Solution Designer
Maps behaviour to Didge capabilities
Implementation Team
Configures Didge features and forms
QA
Validates behaviour against documentation
Delivery Lead
Approves release readiness
Phase 1 – Package Definition (Intent)
Objective
Define what business outcome is required.
Activities
Identify whether the package is:
Functional (by domain)
Operational (by operation)
Document:
business problem
intended outcomes
scope and non-goals
regulatory or standards context
List candidate checkpoints by name only
Deliverables
Package Definition Brief
Exit Criteria
Intent and scope approved by SME
No implementation detail included
Phase 2 – Capability Rinse (Platform Fit Check)
Objective
Confirm how much of the package can be delivered using existing Didge capabilities.
Activities
Review Didge platform features
Classify requirements as:
covered out-of-the-box
covered via configuration
requiring extension (if any)
Deliverables
Capability Rinse Notes (internal)
Exit Criteria
No unnecessary documentation of existing features
Agreement on configuration-first approach
Phase 3 – Checkpoint Design (Control Definition)
Objective
Define what controls must exist and how correctness is enforced.
Activities
For each checkpoint:
Complete the Checkpoint Definition Template
Define:
control purpose
normative (standards-based) rules
contextual configuration options
pass/fail logic
exclusions
Deliverables
Completed Checkpoint Definitions
Exit Criteria
SME sign-off on control intent
Behaviour defined without referencing forms
Phase 4 – Data Acquisition Design (Behaviour)
Objective
Define how data enters the system in real operational conditions.
Activities
For each checkpoint:
Identify one or more Data Acquisition Scenarios
Complete a Data Acquisition Behaviour Sheet per scenario
Define:
required human behaviour
supported acquisition methods (image, manual, post-event)
validation and guardrails
fallback paths
system preconditions
Deliverables
Data Acquisition Behaviour Sheets
Exit Criteria
Behaviour aligns with real operations
Manual and post-event capture supported where required
QA scenarios clearly testable
Phase 5 – Form Design or Selection (Data Capture)
Objective
Enable data capture that supports defined behaviour and controls.
Activities
Select existing forms where possible
Design new forms only if required
Ensure forms:
remain neutral and reusable
expose required configuration parameters
support defined data acquisition scenarios
Deliverables
Form specifications or updated forms
Exit Criteria
No business logic embedded in forms
Forms validated against acquisition scenarios
Phase 6 – Configuration & Assembly
Objective
Configure Didge to realise the package design.
Activities
Configure checkpoints using forms and settings
Apply normative defaults
Pre-configure contextual settings at package level
Assemble Functional and Operational Packages
Deliverables
Configured packages in Didge
Exit Criteria
Configuration matches documented behaviour
No site-level invention required
Phase 7 – Testing & Quality Assurance
Objective
Validate that the system behaves as designed.
Activities
Test each Data Acquisition Scenario end-to-end
Validate:
required inputs
validation rules
fallback behaviour
analytics outputs
Perform regression testing
Deliverables
QA sign-off
Exit Criteria
All scenarios pass
No critical defects outstanding
Phase 8 – Implementation Validation
Objective
Confirm deployability in real environments.
Activities
Deploy to pilot site
Confirm:
onboarding clarity
operational usability
configuration completeness
Deliverables
Implementation sign-off
Phase 9 – Release & Documentation
Objective
Release safely and preserve knowledge.
Activities
Finalise Docs:
package overview
checkpoint references
acquisition scenarios
Version the release
Communicate internally
Deliverables
Released package
Updated documentation
Phase 10 – Post-Release Review
Objective
Capture learnings and improvements
Activities
Gather feedback
Review behaviour vs intent
Log enhancements
Quality Gates Summary
Phase
Gate
Package Definition
Intent approved
Checkpoint Design
SME sign-off
Data Acquisition
Behaviour validated
Configuration
Matches documentation
QA
All scenarios pass
Release
Docs complete
Non-Negotiable Rules
Never design forms before data acquisition
Never assume real-time capture is always possible
Never embed logic in forms
Always support operational fallback paths
Always test behaviour, not just configuration
Intended Use
This SOP is the authoritative procedure for delivering functionality in Didge.
All teams must follow this process for new packages, checkpoints, or major changes.
Last updated
Was this helpful?