What problem does Mou solve?
Every month, legitimate PDS/ONORC beneficiaries are silently cut off from their rations — not because they're ineligible, but because of backend failures: a name spelled differently across Aadhaar and ration card (often across scripts — Bengali vs. English), an incomplete Aadhaar-seeding, or a biometric authentication failure from a fingerprint that's faded with age or manual labor. No notification is sent. They find out only when they're turned away at the ration shop with no explanation.
Existing tools (Mera Ration, state RCMS portals) tell you your card is inactive. None of them tell you why — and none reveal that the same defect is hitting your neighbours too.
The core insight
One rejection looks like personal misfortune. A thousand rejections sharing the same root cause at the same shop is a systemic defect — and Mou is what makes it visible.
This is the inversion that defines Mou: instead of "do you qualify?", we answer "you qualify — here's what's silently breaking it, and here's how to fix it."
How it works
Mou runs a three-stage pipeline:
Stage 1 — Diagnose: A beneficiary (or a caregiver/CSC operator acting as proxy) uploads photos of their Aadhaar and ration card. Google Cloud Vision API extracts identity fields — including Bengali script. We then run transliteration-aware fuzzy matching (indic-transliteration + rapidfuzz) to catch cross-script mismatches a literal string comparison would miss. A set of hardcoded deterministic rules (no LLM on this path) classifies the exact root cause. The Gemini API phrases the result in plain language, with a pre-generated offline fallback so no live API call can break the demo.
Stage 2 — Cluster: Each diagnosis is logged as an anonymised event {root_cause, location, document_pattern}. Events sharing a signature are grouped into a single systemic defect.
Stage 3 — Surface: Clusters are ranked by number of beneficiaries affected — not complaint volume — and displayed on a read-only officials' dashboard, with every cluster expandable to its underlying anonymised cases for audit.
What we built
- Flutter app (citizen-facing, APK): document upload, self-serve or assisted/proxy intake, side-by-side evidence verification, diagnosis result and next step
- FastAPI backend: single source of truth for all AI logic — OCR, matching, rules, clustering
- Next.js dashboard (officials/civil society): read-only view of ranked systemic defects, fed by the same API
- Both frontends consume a single locked JSON API contract — stability by design
Responsible AI
Mou never declares eligibility and never writes to any government record. Every diagnosis is framed as a "likely cause" with the extracted evidence shown side-by-side so the user can verify before acting. Clusters only surface above a confidence threshold and remain auditable. The decision Mou does not make is eligibility determination — that stays with a human official, always.
What we learned
The hardest part wasn't the AI — it was scoping correctly. The temptation is to build a broad benefits navigator. The real insight was narrower and sharper: the failure mode isn't confusing eligibility rules, it's the system silently excluding people who already qualify. That reframe changed everything about the product.
Challenges
OCR accuracy on real phone photos of Indic-script documents was the dominant technical risk — getting Google Cloud Vision to reliably extract Bengali names from photographed (not scanned) ration cards required preprocessing and careful fallback design. Cross-script fuzzy matching (catching "Begum" vs "Begam" as the same name across scripts) required combining transliteration normalization with fuzzy distance, not just one or the other.
