InspiratioInspiration

Living in Delhi, every citizen has faced the nightmare of filing a civic complaint — only to be told "This is not our department." A pothole on your street? Is it MCD or PWD? A sewage overflow? DJB or MCD? Power lines sparking dangerously? Which DISCOM — BSES Rajdhani, BSES Yamuna, or Tata Power?

Delhi's administrative landscape is uniquely fragmented. 10+ agencies share overlapping jurisdictions across the same city — roads are split between MCD (colony lanes < 60 feet) and PWD (arterial roads ≥ 60 feet), drains are divided between MCD (storm water), DJB (underground sewage), and PWD (arterial road drains), and electricity is carved among three private DISCOMs based on invisible geographic boundaries. Areas like Lutyens' Delhi (NDMC) and Delhi Cantonment have entirely separate governance.

Citizens don't know — and shouldn't need to know — these bureaucratic boundaries. They just want their problem fixed.

That frustration inspired Delhi CivicNav: an intelligent system that takes a plain-language complaint and automatically resolves the correct agency, generates formal complaint letters in English and Hindi, and provides the exact helpline numbers and document checklists — eliminating the jurisdictional ping-pong that delays resolution by weeks.

What it does Delhi CivicNav is a full-stack civic grievance routing platform that:

Intelligently Routes Complaints: A citizen types their problem in plain language (e.g., "The sewer outside my house in Rohini has been overflowing for 3 days"). The system uses Elasticsearch-based NLP scoring to classify it into the correct category and dynamically resolve which of Delhi's 10+ agencies is responsible.

Resolves Complex Jurisdictional Overlaps: The routing engine handles real-world boundary conflicts using a layered override system:

Roads: Colony roads → MCD, Main roads/flyovers → PWD, DDA housing roads → DDA Drainage: Underground sewers → DJB, Colony storm drains → MCD, Arterial road drains → PWD Electricity: Dynamically mapped to BSES Rajdhani, BSES Yamuna, or Tata Power based on the citizen's PIN code and locality Special Zones: NDMC and Delhi Cantonment Board override all other agencies Queries Live Public Data: Integrates with the India Post Directory API (api.postalpincode.in) to resolve any 6-digit Delhi PIN code into its administrative district, MCD zone, and electricity distribution boundary in real-time.

Generates Bilingual Complaint Letters: Auto-drafts formal grievance letters in both English and Hindi, pre-addressed to the correct officer designation (e.g., Assistant Engineer, Sewerage Division, Delhi Jal Board), ready for submission.

Provides Escalation Drafts: If an agency rejects the complaint citing jurisdiction mismatch, the system generates a counter-grievance letter addressed to the PGMS (Public Grievance Monitoring System) portal.

Manages Complaint Lifecycle: Citizens can track, edit, and monitor their complaints with full RBAC isolation — each browser session only sees its own complaints, with contact data masked for privacy.

How we built it Architecture The system follows a three-layer architecture:

Frontend (HTML/CSS/JS) → REST API Flask Backend → ES DSL Elasticsearch Scoring Engine Frontend (HTML/CSS/JS) REST API ​ Flask Backend ES DSL ​ Elasticsearch Scoring Engine Search & Scoring Engine We built a high-fidelity Elasticsearch DSL simulator that implements the core query primitives:

bool queries with must, should, and filter clauses multi_match with field-level boosting (e.g., keywords^2 scores keyword matches 2× higher) term exact-match filters for PIN code lookups BM25/TF-IDF approximation for relevance scoring: Score ( q , d

)

∑ f ∈ fields ∣ T q ∩ T d , f ∣ ∣ T q ∣ × 5.0 × β f Score(q,d)= f∈fields ∑ ​

∣T q ​ ∣ ∣T q ​ ∩T d,f ​ ∣ ​ ×5.0×β f ​

where T q T q ​ = query tokens, T d , f T d,f ​ = document tokens in field f f, and β f β f ​ = field boost factor.

The engine tokenizes text with a custom analyzer that handles English pluralization (potholes → pothole, cables → cable) for better recall.

Data Indices Two Elasticsearch indices power the routing:

Index Documents Purpose localities 30+ Delhi neighborhoods Maps PIN codes → MCD zones, DISCOM boundaries, sub-divisions agency_rules 7 complaint categories Maps complaint text → agency, with keywords, templates, and document checklists Public API Integration For PIN codes not in our local index, the system makes a live HTTPS call to:

GET https://api.postalpincode.in/pincode/{pincode} The response is parsed to extract the official post office name, district, and division, which are then translated to MCD zones and DISCOM boundaries using a rule-based mapping engine.

Security & RBAC Persistent browser sessions via localStorage with unique citizen tokens Record isolation: Backend filters complaints by X-User-Id header — citizens only see their own data Contact masking: Phone numbers displayed as 987*****10 for non-owners Document validation: Mandatory Base64 file uploads enforced server-side for specific complaint types Resolved complaint immutability: Backend rejects update requests on resolved complaints with 400 Bad Request Resolution restricted to admins: Citizens cannot mark their own complaints as resolved — only admin-role users can toggle status Frontend A premium dark-themed responsive UI built with vanilla HTML/CSS/JS featuring:

Glassmorphism cards and smooth gradient backgrounds Dynamic form fields that adapt based on complaint type Drag-and-drop file upload with Base64 preview Agency filter dropdown for complaint history Expandable bilingual letter tabs with copy-to-clipboard Challenges we ran into Jurisdictional Ambiguity: The single hardest challenge was accurately modeling Delhi's overlapping civic boundaries. A pothole on the same street could belong to MCD, PWD, or DDA depending on road width, housing authority, and whether the colony has been "handed over" to MCD. We solved this with a cascading override engine that evaluates keyword signals (e.g., "flyover" → PWD, "DDA flats" → DDA) after the primary category match.

DISCOM Boundary Resolution: Delhi's three electricity utilities serve geographically interleaved zones with no clean administrative split. A single PIN code like 110092 covers areas under both BSES Yamuna and Tata Power. We resolved this by combining PIN-level district data from the India Post API with our locality index to determine the correct utility.

Elasticsearch Without Elasticsearch: Building a faithful ES DSL simulator that correctly handles bool query composition, field boosting, and BM25-like scoring without an actual cluster required careful study of Elasticsearch's scoring documentation. We validated our simulator against expected routing outcomes for 4 diverse test cases.

Bilingual Template Engineering: Crafting formal Hindi government letters with correct honorifics (महोदय/महोदया), department hierarchies (सहायक अभियंता / क्षेत्रीय अधिकारी), and placeholder injection while maintaining grammatical correctness across 7 categories was painstaking work.

Session Isolation Without Authentication: Implementing RBAC without a login system required creative use of localStorage tokens and HTTP header-based filtering, while still keeping admin testing accessible via URL parameters.

Accomplishments that we're proud of Accurate routing across 10+ agencies: Our system correctly distinguishes between MCD colony roads vs PWD arterial roads, DJB sewers vs MCD storm drains, and dynamically resolves the correct DISCOM — something even Delhi's own helplines often get wrong.

Zero-dependency public API integration: The India Post API integration means our system can resolve any valid Delhi PIN code, not just the ones in our hardcoded dataset — making it production-scalable.

Complete citizen workflow: From filing a complaint to receiving a pre-drafted bilingual letter with the correct officer's designation, helpline numbers, required document checklist, and an escalation template — all in one click.

Privacy-first design: Contact masking, record isolation, and role-based visibility were baked in from the start, not bolted on as afterthoughts.

The dispute solver: No other civic platform we found generates an escalation letter for when your complaint is rejected. Our dispute draft references the specific agency, zone, and category to argue the jurisdictional case.

What we learned Domain knowledge matters more than code complexity: Understanding Delhi's actual administrative structure (MCD zones, PWD classifications, DISCOM grids, NDMC boundaries) required more research than writing the routing engine itself. The Delhi Municipal Corporation Act, DJB notifications, and DISCOM license areas were our most important references.

Elasticsearch DSL is elegant: Building a simulator taught us how bool queries compose must/should/filter clauses, how field boosting via ^ notation works, and how BM25 scoring balances term frequency against document length.

Public APIs are underutilized gold mines: The India Post PIN code API is free, fast, and remarkably comprehensive — yet almost no civic tech project uses it for locality resolution. Combining it with administrative mapping rules creates a powerful geo-resolution pipeline.

Hindi NLP is hard: Government Hindi uses a very specific formal register (राजभाषा) with standardized honorifics and department naming conventions that differ significantly from conversational Hindi. Getting the tone right required studying actual RTI responses and government circulars.

What's next for Delhi CivicNav 🗺️ Google Maps Integration: Allow citizens to drop a pin on a map instead of typing an address. Use reverse geocoding to auto-fill locality, PIN code, and even detect road width for MCD vs PWD classification.

🤖 LLM-Powered Complaint Summarization: Use a language model to generate more natural, context-aware complaint letters instead of template-based drafts.

📊 Analytics Dashboard: Aggregate complaint data to visualize which agencies have the most pending grievances, average resolution times, and geographic hotspots.

🔔 Real-Time Status Tracking: Integrate with the Delhi Government's PGMS and MCD 311 APIs to provide live status updates on filed complaints.

📱 Progressive Web App (PWA): Convert to a PWA for offline-first mobile support, enabling citizens to draft complaints without internet and submit when connected.

🏛️ Multi-City Expansion: The routing engine architecture is generalizable. With new locality indices and agency rules, it can be extended to Mumbai (BMC/BEST/MMRDA), Bangalore (BBMP/BWSSB/BESCOM), and other Indian cities with similar jurisdictional complexity.n

Built With

• agents
• elasticsearch
• python