Saarthi AI

• 

  Logo

• 

  Home page of UI/UX

Inspiration

India has over 41 million internal migrant workers. When they move states for work, they don't just leave their homes behind — they lose access to nearly every welfare scheme they were enrolled in. A construction worker from Bihar who moves to Hyderabad has to navigate a fragmented system of portals, offices, and paperwork in a language he may not speak, with documents he may not have, while holding down 12-hour shifts.

We wanted to build something that actually met him where he was on a basic Android phone, in Hindi, with a voice interface.

What it does

Saarthi is a mobile-first AI welfare navigator. A migrant worker opens it in any browser, describes their situation by voice or text, and Saarthi tells them which central and state government welfare schemes they may be eligible for, what documents they need, and the exact steps to claim them. A separate emergency flow bypasses all of this and routes users directly to the nearest hospital, shelter, or police — calmly and automatically.

It supports two locations Bihar and Mumbai.

How we built it

The backend is a deterministic linear RAG pipeline built on FastAPI, ChromaDB, and the Groq API (primary model: DeepSeek V-3.2; fallback: LLaMA 3.3 70B). There are no orchestration frameworks. The entire retrieval and synthesis pipeline is a single 40-line Python function.

A hard architectural rule guided every decision: the LLM reasons only over retrieved text. It never computes dates, map coordinates, or eligibility facts. Those come from deterministic Python. This keeps the system auditable and prevents hallucination on the details that matter most.

The frontend is vanilla JS and CSS, no frameworks, max-width 480px. Voice input and output are powered by Sarvam AI's STT and TTS APIs, proxied through the backend so no API key ever reaches the client. The whole thing runs on a single Uvicorn process served on Hugging Face Spaces.

Challenges

The hardest problem was not technical. It was deciding what the system should refuse to answer. Welfare guidance for vulnerable users has real consequences if it is wrong. We built a three-tier guardrail system: out-of-scope queries get a warm redirect, unsupported schemes get a polite decline with official portal links, and situations that genuinely need a human (a workplace accident, extreme document ambiguity) raise an amber interrupt panel that disables further input until the user explicitly acknowledges it. The system cannot be nudged past this gate.

Dependency conflicts between ChromaDB and sentence-transformers cost us hours. The fix was simple: never pin transitive dependencies.

What we learned

Responsible AI is not a checklist you run at the end. The guardrail design, the uncertainty framing in every response ("you may be eligible"), the provenance footer showing verification dates, the human escalation gate: these are architectural decisions, not features. They have to be built in from the start or they never fit.

What's next for Saarthi AI

Expanding to more migration corridors, adding document verification support, introducing more languages, and working with NGOs already on the ground to validate the scheme data with real users.

Built With

• chromadb
• css
• deepseek
• fastapi
• groq
• html
• huggingface
• javascript
• leaflet.js
• llama
• python
• sarvamai
• sentence-transformers