Correcting the execution model for Days 1–3 is crucial: **You do not walk blindly into a high-security government facility asking to audit registers.** You work exclusively through your **Single Point of Contact (SPOC)**—the officer who invited you in—to lock down a strict, agreed-upon scope and produce tangible baseline deliverables within 72 hours. --- ### Revised 18-Day Execution Plan ``` [Days 1–3: SPOC Alignment & Discovery Scope] └── Establish single contact, lock baseline scope, obtain sample artifacts. │ ▼ [Days 4–8: Core Database & Escalation Engine] └── Build CRB-anchored Django models, routing logic, and immutable audit logs. │ ▼ [Days 9–13: Ingestion, OCR & Public Gateway] └── Implement document scanning pipeline, text extraction, and public submission UI. │ ▼ [Days 14–16: Full Lifecycle Stress Testing & RBAC] └── Replicate real-world file escalations and secure role access controls. │ ▼ [Days 17–18: Live Presentation Prep for the DPP] └── Seed local dataset, polish offline execution, and dry-run the demonstration. ``` --- ### Days 1–3: SPOC Ingestion, Scope Definition & 72-Hour Deliverables #### Day 1: Single Point of Contact (SPOC) Alignment at JLOS House * **The Meeting:** Meet your SPOC at JLOS House. Do not request broad access to sensitive files right away. * **The Scope Request:** Agree on a zero-friction scope document. Ask your SPOC for: 1. A 30-minute structured interview mapping the exact physical steps a complaint file takes when received at the desk. 2. Redacted/sanitized copies of **3 core forms**: a *Complaint Lodgement Form*, a *Perusal Minute Sheet*, and a *File Recall Order*. 3. The exact nomenclature used in the primary ledger (e.g., Police CRB Number format, SD Ref format, RSA Station names). #### Days 2–3: Execution of the Discovery Deliverables * Map the SPOC's verbal description directly into a formal **Data Flow Diagram (DFD)** and **Domain Field Dictionary**. * **By Day 3 (72-Hour Mark), Hand Back to Your SPOC:** * **Deliverable 1:** A 2-page *Scope Alignment Document* confirming the exact system boundary (Intake $\rightarrow$ Routing $\rightarrow$ Escalation $\rightarrow$ Directive). * **Deliverable 2:** The complete *Data Schema Draft* showing every field required to capture a complaint against a CRB file. * *Impact:* This proves professional execution immediately and gives your SPOC the confidence to champion your demo on Monday. --- ### Days 4–8: Core Database Architecture & Engine Mechanics * Build the relational database schema anchored on the **Police CRB Number** (`crb_number`). * Model the two distinct complaint categories: * **Conduct Complaints:** Directly routes to the *Directorate of Inspections & Quality Assurance* at JLOS House, bypassing local station officers. * **Process Decision Complaints:** Routes to the *Resident State Attorney (RSA)*, with SLA-based auto-escalation to the *Regional Officer* and *DPP Executive Office*. * Implement an append-only `FileMovementLedger` table that logs every physical file move and administrative directive cryptographically. --- ### Days 9–13: Ingestion, OCR Pipeline & Multi-Channel Ingestion * Build an asynchronous processing queue to handle multi-page scanned PDFs of dockets and petition letters. * Integrate an Optical Character Recognition (OCR) engine to extract text automatically, indexing CRB references, suspect names, and offense details for full-text search. * Build a simple public submission interface that generates a unique tracking reference code for citizens, alongside an internal RSA triage console. --- ### Days 14–16: End-to-End Stress Testing & User Experience Refinement * Run a full simulated scenario: 1. A citizen logs a complaint against a closed theft charge (`CRB 412/2026`). 2. The system routes it to the local RSA; the SLA expires after 7 days without action. 3. The system auto-escalates the file to the Regional Officer, who issues a *File Recall Order*. 4. The DPP re-peruses the docket and issues a binding directive: *Re-instate Charges*. * Lock down strict Role-Based Access Controls (RBAC) so an officer facing an active conduct complaint cannot view or edit the investigation file. --- ### Days 17–18: Live Demo Polish & Presentation Rehearsal * Seed the database with realistic regional station data (e.g., *Mbale RSA Station*, *Soroti RSA Station*, *Kampala HQ at JLOS House*). * Ensure the entire Django application, database, and OCR engine run locally on an offline staging laptop—eliminating any dependence on venue Wi-Fi during the presentation. * Rehearse the presentation script to keep the focus strictly on **statutory compliance, eliminating lost files, and enforcing operational accountability**. --- ### Project Document: ODPP Complaints & Digitization Proof of Concept * **Project Title:** ODPP Complaints Management & File Lifecycle System (PoC) * **Location Anchor:** JLOS House, Katalima Road, Naguru, Kampala * **Core Objective:** Provide an immutable, CRB-anchored digital platform that tracks public and internal complaints, monitors statutory turnaround times, and maintains a cryptographic audit trail for all prosecutorial directives. #### Key Subsystems 1. **Multi-Channel Ingestion Gateway:** Public web form / USSD tracking interface + internal desk intake for paper dockets. 2. **Automated Escalation Matrix:** Enforces statutory escalation hierarchy (RSA $\rightarrow$ Regional Officer $\rightarrow$ HQ Inspections at JLOS House). 3. **Docket Digitization Engine:** Asynchronous pipeline running OCR text extraction and indexing on scanned dockets. 4. **Immutable Movement Ledger:** Cryptographic ledger recording every physical docket location change and administrative order. --- ### Resource Requirements #### Human Resources * **1 Solution Architect / Lead Presenter:** Handles SPOC engagement, domain modeling, architecture, and executive presentation. * **2 Full-Stack Developers:** Implements backend Django models, escalation state machine, OCR pipeline, and frontend UI. * **1 Legal/Domain Advisor:** Reviews legal terminology, statutory SLA windows, and procedural compliance. #### Technical Equipment * **2x High-Performance Workstations:** For local development, database hosting, and async worker execution. * **1x Portable High-Speed Document Scanner:** For demonstrating real-time paper file scanning and OCR extraction during the pitch. * **1x Staging Local Server Environment:** Completely isolated, offline-capable demonstration stack. --- ### What to Request via Your SPOC at JLOS House Do not roam the building. Request these specific artifacts directly through your SPOC on Day 1: 1. **Standard Complaint Intake Schema:** The exact data fields currently recorded when a citizen or attorney lodges a petition. 2. **Sanitized Sample Dockets:** A redacted multi-page paper file (containing a Charge Sheet, Police Form 3, and Perusal Sheet) to train and test the OCR text extraction pipeline. 3. **Regional Station Directory:** The official naming codes and hierarchy list for the 18 Regional Offices and attached RSA court stations. 4. **Target Service Delivery SLAs:** The official turnaround timelines (e.g., maximum target days for RSA file perusal before escalation triggers). --- ### Process Flow of the Complaints Algorithm ``` ┌───────────────────────────────┐ │ Incoming Public/Internal │ │ Complaint (CRB Ref Attached) │ └───────────────┬───────────────┘ │ ▼ ┌───────────────────────────────┐ │ Is Complaint Type == CONDUCT? │ └───────┬───────────────┬───────┘ │ │ YES │ │ NO (Process Decision) v v ┌─────────────────────────────────────┐ ┌─────────────────────────────────────┐ │ Bypass Local Station │ │ Route to RSA at Station of Origin │ │ Route DIRECTLY to Directorate of │ │ Target: Re-perusal of Case Docket │ │ Inspections (JLOS House) │ └──────────────────┬──────────────────┘ └─────────────────────────────────────┘ │ v ┌─────────────────────────────────────┐ │ Resolved at RSA Level within │ │ SLA Window (e.g., 7 Days)? │ └─────────┬─────────────────┬─────────┘ │ │ YES │ │ NO / Dissatisfied v v ┌────────────────────┐ ┌───────────────────────┐ │ Issue Resolution │ │ Auto-Escalate to │ │ Directive & Close │ │ Regional Officer │ └────────────────────┘ └───────────┬───────────┘ │ v ┌───────────────────────┐ │ Resolved at Regional │ │ Level within SLA? │ └─────┬───────────┬─────┘ │ │ YES │ │ NO / Dissatisfied v v ┌──────────────────┐ ┌──────────────────┐ │ Issue Regional │ │ Escalate to DPP │ │ Directive & Close│ │ Executive Office │ └──────────────────┘ └─────────┬────────┘ │ v ┌──────────────────┐ │ DPP Recalls File │ │ & Issues Binding │ │ Directive │ └──────────────────┘ ``` #### Step-by-Step Execution Mechanics 1. **Ingestion & Anchor Registration:** The complaint enters via public or internal desk gateway, binding immediately to `crb_number`. 2. **Category Triage:** * **Conduct Complaints** (misconduct, bribery, file suppression) route directly to HQ Inspections at JLOS House to prevent local tampering. * **Process Decisions** (disagreeing with a sanction or withdrawal) route to the local RSA for initial re-examination. 3. **SLA Monitoring:** Background tasks continuously track open complaints. If the RSA fails to resolve the petition within the SLA window, the state automatically updates to `ESCALATED_REGIONAL`. 4. **File Recall & Directives:** If escalated to HQ, the DPP issues an administrative order calling up the file. The order is recorded in the immutable ledger, updating the master docket status (`REINSTATED` or `SANCTIONED`). --- ## Implementation Index **Index date:** 2026-08-19 **Current repository state:** Documentation and presentation design only. No Django application, database migrations, OCR worker, frontend application, or automated test suite is present in this workspace. ### Status legend | Status | Meaning | |---|---| | `DOCUMENTED` | The requirement or process is described in the source material. | | `DESIGNED` | A visual or technical design exists, but no executable implementation is present. | | `DEPENDENCY` | Work cannot be finalized until ODPP/SPOC information or approval is supplied. | | `NOT STARTED` | No implementation artifact was found in this workspace. | | `CONFLICT` | Source documents use different names or rules and need one approved version. | ### Delivery index | ID | Work item | What is being done | Evidence | Status | Next action | |---|---|---|---|---|---| | `DISC-01` | SPOC alignment and scope | Confirm one SPOC, interview the physical complaint path, and agree the system boundary. | `complaint_system.md`; `source_doc-1787146646564-nmez.txt`; proposal and digitisation documents | `DEPENDENCY` | Obtain the named SPOC and signed scope. | | `DISC-02` | Discovery artefacts | Produce the Scope Alignment Document, Data Flow Diagram, Domain Field Dictionary, and Data Schema Draft within 72 hours. | Markdown plan; Word and HTML companion documents | `DESIGNED` | Create the approved discovery documents from the SPOC interview. | | `DATA-01` | CRB anchor | Bind every complaint and docket record to `crb_number`; resolve missing references before triage completes. | All complaint-flow and proposal documents | `DESIGNED` | Define the canonical CRB/SD formats with ODPP. | | `DATA-02` | Complaint categories | Separate conduct complaints from process-decision complaints. | Complaint Flow Algorithm documents | `DESIGNED` | Approve the category definitions and validation rules. | | `CORE-01` | Relational data model | Build complaint, docket, assignment, directive, SLA, user/role, and station records around the CRB anchor. | Markdown plan; proposal | `NOT STARTED` | Create the Django project, models, migrations, and schema tests. | | `CORE-02` | Routing engine | Route conduct complaints to HQ Inspections and process complaints to the station RSA. | Complaint Flow Algorithm HTML/Word; proposal | `DESIGNED` | Implement and test the state machine after vocabulary is approved. | | `CORE-03` | SLA escalation | Monitor open RSA and regional matters and escalate automatically when the approved SLA expires. | Complaint Flow Algorithm; Digitisation Process; Gantt schedule | `CONFLICT` | Confirm the official SLA; `7` days is currently only a working assumption. | | `AUDIT-01` | Immutable movement ledger | Append every physical movement, directive, recall, and state transition with actor, time, and predecessor hash. | Proposal; Markdown plan; Complaint Flow Algorithm | `DESIGNED` | Define the hash/chain contract and implement append-only persistence. | | `INGEST-01` | Multi-channel intake | Accept public web, toll-free/call-centre, walk-in desk, and email submissions through one intake schema. | Proposal; Digitisation Process; Complaint Flow Algorithm | `DESIGNED` | Build the intake API and internal desk/console interfaces. | | `INGEST-02` | Tracking reference | Issue a unique citizen tracking code at intake and expose status without requiring an account. | Proposal; Digitisation Process | `DESIGNED` | Implement code generation, lookup, notification, and privacy controls. | | `OCR-01` | Docket digitisation | Queue multi-page docket and petition scans for asynchronous OCR. | Proposal; Digitisation Process; Markdown plan | `DESIGNED` | Obtain sanitized samples and select/configure the OCR worker. | | `OCR-02` | Search index | Extract and index CRB references, names, charges, and perusal details for authorized full-text search. | Proposal; Digitisation Process | `DESIGNED` | Implement extraction, indexing, permissions, and confidence/error handling. | | `SEC-01` | RBAC and conflict isolation | Prevent a subject officer from viewing or editing an active conduct complaint and restrict sensitive reads/writes. | Proposal; Complaint Flow Algorithm; Digitisation Process | `DESIGNED` | Implement data-layer authorization and negative access tests. | | `TEST-01` | End-to-end scenario | Validate `CRB 412/2026`: RSA assignment, 7-day expiry, regional escalation, recall order, and reinstatement. | Complaint Flow Algorithm; Markdown plan | `DESIGNED` | Turn the scenario into an automated integration test and demo seed. | | `OPS-01` | Offline demonstration | Run the Django app, database, queue, OCR, and seeded regional data without venue Wi-Fi. | Markdown plan; proposal; Gantt schedule | `DESIGNED` | Build the local staging stack and rehearse the DPP walkthrough. | | `OPS-02` | Pilot and handover | Complete UAT, security review, single-region parallel running, training, runbook, and ICT handover. | Gantt schedule; Digitisation Process; proposal | `NOT STARTED` | Confirm pilot stations, testers, hosting decision, and handover owner. | ### Source and design-system index | ID | File or group | Role | Status | |---|---|---|---| | `SRC-01` | `complaint_system.md` | Master execution plan, requirements, resource list, requested artefacts, and process logic. | `DOCUMENTED` | | `SRC-02` | `Complaint Flow Algorithm.dc.html` and `word/2 - Complaint Flow Algorithm.docx` | Routing diagram, state reference, SLA scenario, and conflict-isolation rule. | `DESIGNED` | | `SRC-03` | `Digitisation Process.dc.html` and `word/3 - Our Digitisation Process.docx` | Six digitisation stages, paper-versus-digital changes, roles, and five delivery passes. | `DESIGNED` | | `SRC-04` | `Gantt Chart ODPP.dc.html` | 13-week schedule covering discovery, design, build, UAT, deployment, and milestones. | `DESIGNED` | | `SRC-05` | `ODPP Proposal.dc.html` and `word/1 - ODPP Proposal.docx` | Technical/commercial case, risks, subsystems, engagement model, security, and approval. | `DESIGNED` | | `SRC-06` | `uploads/source_doc-1787146646564-nmez.txt` | Earlier/revised plain-text execution plan and complaint flow source. | `DOCUMENTED` | | `SRC-07` | `uploads/DPP_Complaint_System.txt` | Empty upload placeholder. | `NOT STARTED` | | `SRC-08` | `doc-page.js` | Generated paged-document web component used by the HTML documents. | `DESIGNED` | | `SRC-09` | `support.js` | Generated document-runtime support bundle used by the HTML documents. | `DESIGNED` | | `SRC-10` | `_ds/.../colors_and_type.css` | SprintTZ visual tokens: `--ink #1B1949`, `--mg #870C71`, `--deep #0d0d20`, `--off #F6F4F8`, `--rule #E2DCE8`, `--muted #6B6070`, `--meta #C8C0D0`, plus Cormorant Garamond and Nunito. | `DESIGNED` | | `SRC-11` | `_ds/.../_ds_manifest.json`, `_ds_bundle.js`, `_adherence.oxlintrc.json`, `README.md` | Design-system component metadata, bundled Badge/Button/PricingCard components, token rules, and usage guidance. | `DESIGNED` | | `SRC-12` | `.thumbnail` | Workspace thumbnail/generated metadata; not a requirements or implementation source. | `NOT APPLICABLE` | ### Decisions required before implementation 1. **Canonical state names:** The HTML/Markdown use `OPEN_RSA`, `OPEN_INSPECTIONS`, `ESCALATED_HQ`, and `RESOLVED_*`; the Word algorithm uses `TRIAGE_CONDUCT`, `ASSIGNED_RSA`, `ESCALATED_DPP`, and `CLOSED`. Select one vocabulary and update every document and future migration. 2. **Day 1 request count:** The Markdown source lists four request groups, while the proposal lists five because it separates the three redacted forms from the sanitized sample docket. Confirm whether the approved request is four groups or five artefacts. 3. **SLA:** Confirm the statutory turnaround period. The current `7`-day value is explicitly provisional. 4. **Pilot boundary:** Confirm the first regional office, attached RSA stations, hosting location, UAT participants, and data-retention rules.