> 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/data-acquisition/data-acquisition-and-user-behaviour.md). # Data Acquisition & User Behaviour Didge Design Guide – Data Acquisition & User Behaviour *** ### Purpose of This Document This document defines how Data Acquisition and User Behaviour should be designed, documented, and implemented within the Didge platform. It establishes a shared mental model for: * how data enters the system * what behaviour is expected from users * how technology supports that behaviour * how configuration enables correct execution This guide is internal-facing and is intended for: * product and domain leads * implementation and solution design teams * engineers and QA * training and onboarding teams *** ### Why Data Acquisition Needs Its Own Design Layer In Didge, most failures do not occur because of missing features, but because of a misalignment between real-world behaviour and system design. Examples: * staff are too busy to take photos at the moment of disposal * disposal happens in different physical locations * weighing may occur later or elsewhere Data Acquisition design ensures that: * the system fits operational reality * users are not forced into unnatural workflows * data remains accurate even under pressure *** ### Position in the Didge Design Framework Data Acquisition sits between checkpoints and forms. > Packages define outcomes > Checkpoints define controls > Data Acquisition defines behaviour > Forms define data structure > Configuration makes it executable This layer describes *how* a control is executed in the real world. *** ### What Data Acquisition Is (and Is Not) #### Data Acquisition IS: * behaviour-focused * scenario-based * technology-aware * tolerant of operational variability #### Data Acquisition IS NOT: * UI or screen design * form field specification * technical implementation detail *** ### Core Concept: Data Acquisition Scenarios All data enters Didge through Data Acquisition Scenarios. A scenario describes: * when data is captured * who captures it * what they physically do * how they interact with technology Scenarios are designed before forms and configuration. *** ### The Four Layers of Data Acquisition Every scenario must address four distinct layers. #### 1. Intent Why the data is being captured. #### 2. Human Behaviour What the person does in the real world. #### 3. Technology Interaction How the person uses Didge, CamPro, or other tools. #### 4. System Preconditions What must already be configured for this to work. Keeping these layers separate prevents confusion. *** ### Data Acquisition Behaviour Sheet (Standard Template) The following template must be used to document each Data Acquisition Scenario. *** #### 1. Data Being Acquired Checkpoint: Purpose: *** #### 2. Acquisition Scenario Scenario Name: When this occurs: *** #### 3. Required Human Behaviour Describe what the person does in the physical world. *** #### 4. Technology Interaction Describe how the user interacts with: * CamPro * Didge mobile app * Didge web platform Avoid UI-level detail. *** #### 5. Supported Acquisition Methods List all allowed capture methods: * ☐ Image-based capture * ☐ Manual entry (mobile) * ☐ Manual entry (web) * ☐ Post-event entry *** #### 6. Validation & Guardrails Define what is required for submission: * mandatory fields * AI confidence thresholds * prompts for missing data *** #### 7. System Preconditions Define what must exist before this scenario can work: * configured locations * categories * units of measurement * user access *** #### 8. Failure & Fallback Behaviour Describe what happens when: * capture is missed * image cannot be taken * weight is unavailable *** #### 9. Data Outcome Describe what the system produces: * records created * flags applied * reporting availability *** ### Design Rules (Non-Negotiable) * Behaviour drives system design, not the other way around * Post-event entry must be supported where operationally necessary * Data quality must be protected through validation, not user discipline * AI assists, but manual fallback must always exist * Scenarios must be testable by QA *** ### How This Is Used in Practice 1. Package defines *what must be measured* 2. Checkpoint defines *what control exists* 3. Data Acquisition Scenarios define *how data enters the system* 4. Forms and configuration are aligned to these scenarios 5. QA tests each scenario end-to-end *** ### Common Mistakes to Avoid * designing forms without understanding behaviour * assuming capture always happens in real time * forcing image capture when operationally unrealistic * hiding fallback paths *** ### Intended Use This document establishes the standard approach for designing Data Acquisition in Didge. All new packages and checkpoints must consider Data Acquisition Scenarios before implementation. --- # 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/data-acquisition/data-acquisition-and-user-behaviour.md?ask=&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.