Back to work
GovTech Law Enforcement Live deployment

How I Built an AI Case Management
System for Uttar Pradesh Police

A production AI system that processes Hindi and English documents, tracks legal notices across an 8-stage approval workflow, and gives officers instant access to 7,849+ records — in a district that had zero digital infrastructure before.

Client Uttar Pradesh Police Dept.
Deployment Chandauli District
Type AI Case Management · Decision Intelligence
Status Live in production
The challenge Unstructured Hindi & English case documents with zero digital infrastructure
The solution End-to-end AI system: document extraction, workflow tracking, cross-station search
Core stack GPT-4o · React 19 · Node.js · PostgreSQL · AWS
Key result 70% reduction in admin work · 10+ hours saved per officer per week

Police officers in Chandauli District were drowning in paperwork — and no one had a clear picture of what was happening across the district at any given moment.

Every legal notice, every case file, every offender record existed on paper. Some documents were in Hindi. Some in English. Most were a mixture of both. Finding a specific case meant physically searching through stacks of files at the station. Tracking where a legal notice sat in an approval process required phone calls, in-person visits, and hope.

The formal process required every legal notice to pass through 8 approval stages before resolution. In practice, notices would stall at a stage for days — or weeks — because no one knew they were waiting. Supervisors had no visibility into backlogs. Officers couldn't tell whether a notice they'd filed two months ago had been resolved or simply lost.

The cross-station problem was worse. Chandauli District covers 18+ police stations. A suspect could have a prior record at three different stations — and an officer at any one of them would have no way to know. Identifying repeat offenders required manual coordination between stations, which rarely happened in practice.

"Officers weren't failing because of incompetence. They were failing because the tools expected them to operate as filing clerks. The paperwork was consuming the hours that should have gone to actual policing."

When I was brought in, the ask was to digitise the process. What I actually built was something more useful: a system that made the existing workflow visible, searchable, and intelligent — without asking officers to change how they worked.

I spent the first two weeks embedded with the team before writing a single line of code. The goal was to understand how cases actually moved — not the official flowchart, but the real process: where documents got stuck, what workarounds officers had already invented, and what they actually needed versus what the spec described.

Three things became clear quickly:

01

Language is infrastructure. Documents arrived in Hindi, English, and a transliterated blend of both (Hindi written in English script). Any AI solution that handled English confidently but struggled with Hindi-English code-switching would fail within a week of launch. The AI extraction layer had to treat both languages as equal first-class inputs from the start.

02

The approval workflow was the real bottleneck. Officers had the documents. What they lacked was visibility into where each notice sat in the 8-stage process, and why things stalled. The AI extraction was valuable — but making the workflow itself transparent was the higher-leverage intervention.

03

Search speed is a binary outcome. If officers could find a case in under 2 seconds, they'd use the system. If search felt slow, they'd reach for the paper file. Performance wasn't an optimisation problem — it was a product requirement.

The design principle that followed: build the minimum system that makes the existing workflow visible and searchable. Then layer AI on top of that foundation. Don't ask officers to change how they think about their work.

Six capabilities, each solving a specific failure mode from the old paper-based system:

01
Multilingual AI Document Extraction

GPT-4o processes Hindi and English documents interchangeably — including transliterated Hindi — extracting structured case data with 95%+ accuracy. Documents that used to take an officer 20 minutes to manually file are processed in under 30 seconds.

02
8-Stage Approval Workflow

Every legal notice is tracked through all 8 approval stages with real-time status. Supervisors see exactly what's stuck, who's responsible, and how long it's been waiting. Automated escalation alerts replace the manual phone calls.

03
Cross-Station Repeat Offender Detection

Officers can instantly check whether a suspect has prior records at any of the 18+ connected stations in Chandauli District — a lookup that previously required manual coordination between stations and often didn't happen at all.

04
Instant Case Search

Full-text and semantic search across 7,849+ documents returns results in under 2 seconds. Officers can search by name, case number, offence type, station, or free text — in Hindi or English.

05
Role-Based Access Control

Officers see their station. Supervisors see their jurisdiction. District HQ sees everything. Access is enforced at the data layer — not just the UI — so sensitive records are protected without relying on officers remembering to close a tab.

06
Document Upload & Processing

Officers upload documents via browser — any format, any scan quality the department had been using. The system extracts, classifies, and indexes within seconds. No training required. The interface was designed for first-time use without documentation.

I built the system in three phases, each with a hard acceptance criterion before moving to the next.

Phase 1

Document Intelligence Layer

The extraction pipeline used GPT-4o with custom prompting built around the legal terminology specific to Indian law enforcement — notice categories, offence classifications, and the way dates and names appear in Hindi-English police documents. Every extraction was scored against confidence thresholds; anything below 85% confidence was flagged for manual review rather than silently accepted. Testing used real (anonymised) documents from week one, not synthetic samples — this surfaced edge cases that clean test data would have hidden entirely.

Phase 2

Case Management Core

PostgreSQL modelled the full case lifecycle — from initial notice creation through each approval stage to resolution. WebSocket connections gave officers real-time status updates without page refreshes, so a supervisor approving a notice at district HQ was visible to the station officer within seconds. The repeat offender identification queried across all station records using normalised name matching with fuzzy search to handle transliteration variations in how the same name could appear across documents.

Phase 3

Interface, Search & Deployment

The React 19 frontend was built around a search-first design: the most important action — finding a case — required one interaction. The document upload flow handled variable scan quality with processing feedback so officers knew their document was being handled. The system was deployed on AWS with Nginx proxying and Cloudflare fronting for performance and DDoS protection. Load testing was run against realistic concurrent usage before handover to ensure the 2-second search guarantee held under actual district-level traffic.

01 Frontend
React 19 TypeScript WebSocket Streaming UI RBAC
02 AI & Extraction Core
GPT-4o Custom Prompting Confidence Scoring Hindi NLP Semantic Search
03 Backend & APIs
Node.js Express REST WebSocket Document Processing
04 Data
PostgreSQL Full-text Search Fuzzy Matching 26K+ Records
05 Infrastructure
AWS Docker Nginx Cloudflare CI/CD
Impact

Numbers from
live deployment.

Measured after full rollout across Chandauli District. These are operational metrics from the production system, not projections.

70% Reduction in administrative work per officer
95%+ AI document extraction accuracy (Hindi & English)
10+ Hours saved per officer per week
7,849 Documents in active use across the district
26K+ Total records tracked across all stations
18+ Police stations connected and live
What I learned

Four things this project taught me about building AI for government.

  1. 01

    Language is infrastructure, not a feature

    Treating Hindi and English as equal first-class inputs from day one prevented a full rewrite six weeks in. The AI pipeline needed specific prompting strategies for transliterated Hindi (Hindi written in English script) that would not have been obvious from any product spec. Discovering this during development rather than in production made the difference between a 2-week fix and a 2-month rebuild.

  2. 02

    Workflow visibility beats AI augmentation — at first

    Officers didn't initially need smarter AI. They needed their existing 8-stage process made visible and searchable. Once the workflow was transparent — once supervisors could see what was stuck and why — the AI document extraction became genuinely transformative. The order mattered: build trust with visibility, then add intelligence on top of a foundation people already depend on.

  3. 03

    Test with real data from day one, no exceptions

    Synthetic test documents do not match real police paperwork. Real documents have handwriting margin notes, inconsistent formatting, scan artefacts, and legal abbreviations that don't appear in any standard corpus. Testing with actual (appropriately anonymised) notices from week one surfaced extraction edge cases that clean test data would have hidden entirely — cases that would have been silent production failures.

  4. 04

    Speed is a binary outcome, not a performance metric

    When officers find a case in under 2 seconds, they use the system. When it takes 5 seconds, they reach for the paper file. This isn't about user preference — it's about how trust in a tool is built or lost in the first week. Performance optimisation on the search layer was not premature; it was a prerequisite for adoption. In GovTech, adoption is the hardest problem you'll face.

Building something similar?

Let's work together.

I take on 1–2 new consulting projects per quarter. If you're building AI for government, enterprise, or finance — let's talk.