Raahnuma

Raahnuma ('guide' in Urdu), AI that turns Pakistan's confusing welfare rules (BISP, Sehat Card, Taleemi Wazaif) into plain answers on what you may qualify for, and your next step.

Comment

Raahnuma — AI Benefits Navigator for Pakistan's Social Protection System

Inspiration

In Pakistan, over 9 million families receive cash transfers through the Benazir Income Support Programme (BISP) — but millions more qualify and don't know it. The eligibility rules are buried in bureaucratic language, spread across multiple agencies, and change by province. A daily-wage worker in Rawalpindi doesn't know his household's PMT score. A pregnant woman in rural Sindh doesn't know that Nashonuma nutrition support exists — or that she can only register in person at a District Headquarters Hospital, not online. A family in Punjab doesn't realize their CNIC is their Sehat Card, but it only covers in-patient treatment at private hospitals — not the OPD visit they actually need.

The system isn't broken because programs don't exist. It's broken because people can't see what they're eligible for, and nobody explains it in plain language.

We built Raahnuma (Urdu: رہنما — "guide") to fix that.

What it does

Raahnuma is an AI-powered benefits navigator that takes a person's situation — described in their own words — and maps it against Pakistan's actual social protection programs to surface what they may qualify for, why, and exactly what to do next.

The user journey:

  1. Describe your situation — in plain language, Urdu or English: "I'm a student at FAST, my dad lost his daily-wage job, we're 6 people in Rawalpindi, my younger sister is in class 4"
  2. Answer targeted follow-ups — Raahnuma asks only what's missing: province on CNIC, household composition specifics, pregnancy/disability/school-age children
  3. Get program-by-program results — each as a card showing:
    • Eligibility status: "Likely Eligible" / "May Be Eligible" / "Likely Not Eligible" — never "You Qualify"
    • Plain-language explanation: the specific rule that suggests eligibility, cited directly
    • Required documents: CNIC, B-Form, school enrollment certificate, etc.
    • Exact registration channel: SMS to 8171, visit DHQ hospital, check via 8500 — not a generic "contact your local office"
    • Cross-program alerts: "Because you may qualify for Kafaalat, your school-age sister may also unlock Taleemi Wazaif (education stipend of Rs. 2,500–4,500/quarter)"

Programs covered (Phase 1): | Program | Type | Key Benefit | |---------|------|-------------| | Benazir Kafaalat | Cash Transfer | Rs. 14,500/quarter for households with PMT score < 32 | | Taleemi Wazaif | Education Stipend | Rs. 2,500–4,500/quarter for school-age children of Kafaalat beneficiaries | | Nashonuma | Nutrition Support | Specialized nutrition for pregnant/lactating women & children under 2 | | Sehat Sahulat (PM Health Card) | Healthcare | Free in-patient treatment (coverage varies by province) | | Ramzan Relief | Seasonal Aid | Flat-eligibility food packages during Ramadan |

How we built it

Architecture — Why This Needs Both Rules AND an LLM

This is the core design decision. A pure rules engine can check "is PMT score < 32?" — but real users don't know their PMT score. They say "my dad's a daily-wage worker and we have 6 people at home." A pure LLM can interpret that — but it will hallucinate eligibility thresholds and invent programs that don't exist.

Raahnuma uses a hybrid architecture:

User Input (free text)
       │
       ▼
┌──────────────────────────┐
│  LLM LAYER 1: PARSING    │  Extracts structured profile from natural language:
│  (Situation → Profile)   │  province, income_type, household_size, school_age_children,
│                          │  pregnancy_status, disability, employment_type
└──────────┬───────────────┘
           │
           ▼
┌──────────────────────────┐
│  LLM LAYER 1B: FOLLOW-UP │  Identifies missing critical fields
│  (Gap Detection)         │  Generates targeted questions (not a generic form)
└──────────┬───────────────┘
           │
           ▼
┌──────────────────────────┐
│  RULES ENGINE             │  Hard-coded eligibility logic per program:
│  (Deterministic Matching) │  PMT proxy thresholds, province gates, dependency
│                          │  chains (Kafaalat → Taleemi Wazaif → Nashonuma),
│                          │  age/category requirements
│                          │  Output: LIKELY / MAY_BE / UNLIKELY per program
│                          │  + which conditions met/unmet/unknown
└──────────┬───────────────┘
           │
           ▼
┌──────────────────────────┐
│  LLM LAYER 2: EXPLANATION │  Takes rules engine output + user profile
│  (Results → Plain Language)│  Generates per-program explanation citing
│                          │  specific rules, documents needed, and
│                          │  exact registration channel
│                          │  Applies responsible AI framing throughout
└──────────────────────────┘

Why this justifies AI over a static tool:

  • Situation parsing — An LLM can take "my dad lost his job and we're 6 people" and extract {income_type: "unemployed", household_size: 6}. A form can't handle the infinite ways people describe their lives.
  • Cross-program reasoning — Qualifying for Kafaalat unlocks Taleemi Wazaif and Nashonuma. The rules engine tracks these dependency chains; the LLM explains them in context: "Because your household may qualify for Kafaalat, your sister in class 4 may also be eligible for Taleemi Wazaif."
  • Provincial variation handling — Sehat Card coverage depends on which province is on your CNIC. The same person gets different answers in Punjab vs. KP vs. federal territory. A static FAQ can't navigate this.
  • Graceful handling of incomplete information — Real users don't have all details upfront. The system reasons about what it knows and what it still needs, asking only relevant follow-ups.

Technical Stack

  • Frontend: Next.js with a conversational intake UI → results dashboard
  • AI/LLM: Google Gemini API (free tier) for situation parsing + explanation generation
  • Rules Engine: Deterministic Python logic with structured JSON rule-sets per program
  • Data: Hand-compiled from official BISP/government sources, structured as machine-readable eligibility rules

Challenges we ran into

  1. Eligibility criteria are written for bureaucrats, not citizens. BISP's PMT scoring system uses the National Socio-Economic Registry (NSER) Dynamic Survey — but the formula is not public. We had to design a proxy estimation system based on the known correlates (household size, income type, assets, location) that honestly communicates uncertainty rather than pretending precision.

  2. Provincial fragmentation is real. Sehat Sahulat / PM Health Card operates differently across provinces — Punjab only covers private hospitals, KP and Balochistan have their own schemes, and federal territory has separate administration. Getting this right required mapping each province's implementation separately.

  3. The "false confidence" trap. Our biggest responsible AI challenge: if someone asks "am I covered by Sehat Card?" and we say yes without clarifying that OPD visits aren't covered, they might skip going to a hospital for a checkup thinking they'll be billed — or go to a government hospital in Punjab where the card doesn't work. We had to design the output language to be precise about what IS and ISN'T covered.

Accomplishments we're proud of

  • Cross-program dependency chains — No existing tool in Pakistan tells you "qualifying for Program A also unlocks Programs B and C." Raahnuma does this automatically.
  • Province-aware reasoning — Two users with identical income but CNICs from different provinces get correctly different healthcare coverage explanations.
  • "May qualify" framing throughout — We never say "you qualify." Every output is framed as guidance, not determination. Final eligibility is always BISP/NSER's job via the PMT survey.
  • Real registration channels — Not "contact your local office." Actual SMS codes (8171 for Kafaalat, 8500 for Sehat Card), specific portal URLs, and in-person requirements (Nashonuma at DHQ/THQ hospitals only).

What we learned

Pakistan's social safety net is more comprehensive than most citizens realize — the problem isn't the programs, it's the information architecture around them. Five programs serving overlapping populations, administered by different agencies, with eligibility rules written in bureaucratic language and registration channels ranging from SMS to in-person-only. The gap between "programs exist" and "people access them" is almost entirely an information design problem — and that's exactly where AI reasoning adds genuine value over a static website.

What's next for Raahnuma

  • Urdu-first conversational interface — Full Urdu NLP for users who aren't comfortable in English
  • Voice input — Many target beneficiaries have limited literacy; voice-based intake removes the biggest barrier
  • Real-time program updates — Connect to official BISP/government feeds to automatically update eligibility rules when programs change
  • Community health worker mode — A "case manager" view for Lady Health Workers and BISP field staff doing household surveys
  • Expansion to provincial programs — Punjab's Himmat Card, KP's Insaf Card, and other province-specific schemes

AI Architecture Explanation

(1) Inputs: Free-text situation description in English or Urdu ("I'm a daily-wage worker with 6 family members in Lahore, my wife is pregnant") + structured follow-up responses (province on CNIC, employment type, school-age children count, pregnancy/disability status).

(2) AI Capability: Natural language understanding (situation → structured profile extraction), retrieval (matching profile against program eligibility criteria), classification (per-program eligibility determination), and natural language generation (plain-language explanation with confidence framing).

(3) Processing: The LLM parses free-text into a structured household profile, identifies missing critical fields, and generates targeted follow-ups. A deterministic rules engine then evaluates each of the 5 programs' eligibility conditions against the profile, outputting LIKELY_ELIGIBLE / MAY_BE_ELIGIBLE / LIKELY_NOT_ELIGIBLE with a breakdown of which conditions are met, unmet, or unknown. The LLM then generates per-program plain-language explanations citing the specific rules, required documents, and exact registration channels.

(4) Outputs: A ranked dashboard of program cards, each showing eligibility status (never "you qualify"), a one-paragraph explanation citing specific eligibility rules, required documents list, the exact registration channel (SMS code, portal URL, or in-person location), and cross-program alerts ("qualifying for X may also unlock Y"). A persistent disclaimer frames all outputs as guidance, not determination.

Human-in-the-Loop Design

Raahnuma never determines eligibility. The system's entire job ends at "here is what you may qualify for, here's the specific rule that suggests this, and here's how to verify." Final eligibility determination is performed by BISP through the National Socio-Economic Registry (NSER) Dynamic Survey and Proxy Means Test (PMT) scoring — a process that requires an in-person household survey by trained enumerators. This is a deliberate design boundary: the AI assists with information navigation and interpretation, but the consequential decision (approve/deny benefits) remains with the human-operated government system. We enforce this boundary through language design ("may qualify," never "you qualify"), explicit next-step instructions directing users to official verification channels, and a standing disclaimer on every result.

Responsible AI Guardrail

Risk: False confidence leading to missed care (Sehat Sahulat coverage gap).

A user in Punjab asks "am I covered by Sehat Card?" Raahnuma could say "yes" — but the Sehat Card in Punjab currently only works at private hospitals, and only covers in-patient treatment (not OPD visits or routine checkups). If the user assumes full coverage and skips a needed checkup, or goes to a government hospital expecting the card to work, the AI's output has caused real harm through false confidence.

Mitigation: Every Sehat Sahulat result includes province-specific coverage details: which hospital types are covered, the in-patient-only limitation, and explicit mention of what is NOT covered. We use differential output — two users in different provinces see different coverage explanations — rather than a generic "you're covered" response. All results include the 8500 SMS verification channel so users can confirm their specific coverage before acting on it.

Decision Impact Statement

Before Raahnuma: Amina is a pregnant woman in rural Sindh. Her husband is a daily-wage laborer. She doesn't know her family's PMT score, has never heard of the Nashonuma programme, and doesn't know that her CNIC works as a health card. She misses Rs. 14,500/quarter in cash transfers, nutritional support for her pregnancy, education stipends for her school-age son, and free in-patient healthcare — not because she doesn't qualify, but because she doesn't know these programs exist or how to apply.

After Raahnuma: Amina describes her situation in one paragraph. Raahnuma identifies that she may qualify for 4 programs, explains each in plain language, tells her to SMS 8171 to check Kafaalat status, informs her that Nashonuma registration must happen in person at the nearest DHQ hospital, and explains that her CNIC is her Sehat Card for in-patient care. She goes from "I don't know what's available" to "I know what to check and where to go" in under 3 minutes.

Data Disclosure

All eligibility data was hand-compiled from publicly available government sources:

  • BISP official website and circulars (bisp.gov.pk)
  • Sehat Sahulat Programme official portal
  • Pakistan Bureau of Statistics (NSER methodology)
  • Provincial health department websites (Punjab, KP, Balochistan, Sindh)
  • News coverage of program updates (Dawn, Geo, The News)

No real user data was collected or used. All demo personas are synthetic, designed to represent realistic Pakistani household compositions across different provinces, income levels, and family structures. Synthetic personas were created based on our team's lived understanding of Pakistani household demographics.

Built With

Share this project:

Updates