> 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/ridgy-vision-ai/admin/ridgy-dev-cycle.md).

# Ridgy Dev Cycle

***

### 1. Purpose

The RIDGY App Deck provides a structured methodology for turning business requirements or problem statements into deployable apps on the DIDGE platform.

This framework ensures:

* Clear understanding of business problems.
* Feasibility checks for data capture.
* Streamlined user experience (UX).
* Consistent technical flow for image-based data acquisition, AI processing, and integration into business operations.
* Actionable outputs such as reporting, dashboards, and automated notifications.
* Opportunities for value-add insights beyond the core requirement.

***

### 2. Process Overview

#### Step 1. Define the Business Requirement / Problem Statement

* Document the business need or challenge clearly.
* Example: *“As part of CCP monitoring for incoming goods, supplier and temperature checks are recorded on paper, which leads to falsification risks and inefficiencies.”*
* Identify:
  * Why the process matters (compliance, efficiency, safety).
  * Pain points with existing methods (paperwork, manual data entry, reliability).
  * Desired outcomes (real-time capture, reduced errors, streamlined compliance).

***

#### Step 2. Feasibility Assessment

Determine if the requirement can be solved using RIDGY’s single-point data capture principle.

* Key questions:
  * Can all required data be captured in a single image (or tightly related images)?
  * Is the data consistently present in the captured medium (e.g., invoice, label, sensor reading)?
  * Is the capture practical for users in the production environment?
  * Does the workflow require multi-step data collection? If yes → should be handled in DIDGE Native instead.

Outcome: Proceed with RIDGY only if feasible for single-point capture.

***

#### Step 3. Value-Add Beyond the Problem Statement

Once the core requirement is satisfied, assess what additional insights can be extracted from the same capture to deliver more value to the customer.

* Creative / contextual data opportunities:
  * Invoice images: extract supplier, PO, batch codes, delivery timestamps, anomalies in item lists.
  * Thermal images: detect frost buildup, poor sealing, repeated hotspots.
  * Cold storage photos: identify cleanliness issues, door left open, or stock placement errors.
* Customer-serving outcomes:
  * Anticipate reporting needs (compliance trends, efficiency analytics).
  * Surface hidden operational risks SMEs know are critical but not obvious in the original problem statement.
* Collaboration model:
  * SMEs contribute operational insight (“what else matters”).
  * Technical experts validate whether AI/image processing can realistically capture that data.
  * Together, they design flows that go beyond compliance into operational excellence.

***

#### Step 4. Single-Point Data Capture & Acquisition

#### (End User UX)

RIDGY apps eliminate manual form-filling. The only UX is image capture.<br>

Capture methods:

* CamPro (native Android app with sensors, probes, IoT beacons).
* DIDGE Operation (image upload via QR code or file upload).
* Thermal Imaging (FLIR integration).
* Native Device Camera (standard photo).
* Sensor / Beacon Integration for added context (location, environment).

***

#### Step 5. Extraction, Structuring & Routing

#### (Async / Backend)

* Images flow into DIDGE backend.
* RIDGY AI (Initial Processing): Extracts enough information to populate the webhook and trigger correct routing.
* Webhook + Router Operation:
  * Direct data to the correct downstream operation.
  * Ensure structured submission into DIDGE workflows.

***

#### Step 6. Business Solution Fulfillment

* RIDGY AI (Final Processing): Performs deeper extraction and structuring for the target operation.
* Parent Operation: Receives structured data submission.
* Child Operations: Triggered as needed for additional workflows.
* Reporting & Actions:
  * Dashboards, data tables, performance reports.
  * Automated triggers (emails, WhatsApp messages, DIDGE actions).

End Result: The original business requirement is fulfilled, plus any value-added insights identified in Step 3.

***

### 3. Key Design Principles

* Simplicity: One capture = one workflow.
* Automation: No manual entry; AI handles extraction and routing.
* Scalability: Router + webhook allow flexible branching into multiple operations.
* Auditability: Structured reporting ensures traceability and compliance.
* Value Creation: Always look beyond the problem statement for added customer benefit.
* Collaboration: SME + technical expert pairing is critical for success.

***

### 4. Example Use Case

* Requirement: Capture supplier, temperature, and product details without paper forms.
* Feasibility: Invoice contains supplier + PO info; probe/thermal image captures temperature.
* Value-Add: AI also captures delivery timestamp, batch codes, or flags missing CCP fields.
* Capture: User snaps invoice + probe reading via CamPro.
* Routing: AI extracts supplier + PO → webhook routes to “Incoming Goods CCP” operation.
* Fulfillment: Parent operation logs CCP check, triggers child task for supervisor review, and updates dashboards.

***

<br>


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.didge.io/home/ridgy-vision-ai/admin/ridgy-dev-cycle.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.