AWS Builder Center
Building Sahayak: Designing an AI-Powered Government Scheme Navigator with AWS, Cedar, and Multi-Service Architecture

Building Sahayak: Designing an AI-Powered Government Scheme Navigator with AWS, Cedar, and Multi-Service Architecture

A technical deep dive into how we built Sahayak, an AI-powered government scheme navigator that helps users discover welfare schemes, understand eligibility, and prepare grievance applications. The article covers the system architecture, Go backend, AWS services, Amazon Bedrock, Cedar-based authorization, PostgreSQL, and the challenges we faced while building the platform.

Building Sahayak: An AI-Powered Government Scheme Navigator with AWS and Cedar

Why We Built Sahayak

India has a large number of government welfare schemes covering healthcare, housing, employment, agriculture, education, and financial assistance. The challenge is not a lack of schemes. It is the difficulty of discovering the right one, understanding its eligibility requirements, and knowing what to do when an application is delayed or a benefit never arrives.
The problem is sharper for people with limited digital literacy, such as daily-wage workers, street vendors, farmers, and other underserved communities.
We wanted to build a digital assistant for government welfare schemes, not just another scheme directory. That idea became Sahayak: GovScheme Navigator.
Sahayak helps users discover relevant schemes, understand their eligibility, and prepare grievance applications when something goes wrong with a scheme or benefit. We kept the interaction as simple as possible and grounded important decisions in structured scheme information rather than relying entirely on generative AI.

What Sahayak Does

1
2
3
4
5
6
7
8
9
10
11
12
13
User
│
▼
Sahayak
│
├── User Profile
├── Scheme Discovery
├── Eligibility Evaluation
├── Scheme Information
└── Grievance Assistance
│
▼
AI-generated Draft
A user provides details such as state, occupation, income, age, and family information. Sahayak identifies relevant schemes and explains why the user may or may not meet particular eligibility requirements.
If the user has already applied and is facing a problem, such as a delayed benefit or a missing status update, Sahayak can generate a structured grievance draft addressed to the appropriate authority.

Architecture

We designed Sahayak as a multi-service architecture in which each part of the system has a clearly defined responsibility.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
+---------------------+
| Frontend |
| React + Vite |
+----------+----------+
|
| HTTP / JSON APIs
v
+-------------------------------------------------------------+
| Go Backend |
| |
| Auth, Profiles, Eligibility |
| Grievances, Authorization |
+--------+---------------------+---------------------+--------+
| | AI requests |
v v v
+-----------------+ +-----------------+ +-----------------+
| PostgreSQL | | Cedar Policies | | Python/FastAPI |
| | | Authorization | | AI Service |
+-----------------+ +-----------------+ +--------+--------+
|
v
+-----------------+ +-----------------+
| Java Backend | | AWS AI / |
| Scheme Data / | | Foundation |
| Rules Pipeline | | Model Services |
+-----------------+ +-----------------+
Instead of putting everything into one backend, we separated responsibilities across services. This mattered because scheme data, deterministic eligibility logic, authentication, and generative AI all have very different requirements.

Technology Stack

Frontend: React + Vite

The frontend provides the user-facing interface for:
  • User registration and authentication
  • Profile information
  • Government scheme discovery
  • Eligibility checking
  • Scheme details
  • Grievance generation
We kept the frontend focused on presentation and interaction, and moved business logic to the backend services.

Go Backend

The main application backend is written in Go. It handles:
  • Authentication
  • User accounts and profiles
  • Scheme APIs
  • Eligibility and grievance workflows
  • Database operations
  • Authorization checks
Go gave us a lightweight, efficient foundation for building APIs and service-oriented backends. For database access we used PostgreSQL, pgx, and sqlc. With sqlc we write SQL directly and generate type-safe Go code from it.

PostgreSQL

PostgreSQL is the primary persistent data store. It contains entities such as:
1
2
3
4
accounts
profiles
schemes
scheme_rules
A scheme stores its name, description, state, source URL, last verification time, and responsible department. Eligibility rules live separately in scheme_rules, because scheme metadata and eligibility conditions are different kinds of information.
1
2
3
4
5
6
7
8
9
10
11
Scheme
├── Name
├── Description
├── State
├── Department
└── Source

Rules
├── Age >= 18
├── Occupation = street_vendor
└── Income <= threshold
This gives us a structured representation that can be evaluated deterministically.

Deterministic Rules + Generative AI

One of our most important architectural decisions was not to let the LLM decide eligibility by itself.
Generative AI is excellent at understanding natural language, explaining information, and generating drafts. Eligibility, however, is fundamentally a rules-based problem. If a scheme requires:
1
2
3
Age >= 18
Occupation = farmer
Income <= ₹20,000/month
we don't want an LLM guessing whether someone qualifies. The application evaluates the structured rules instead.
The AI layer is used where it adds the most value:
  • Understanding user input
  • Explaining scheme information
  • Supporting natural-language interaction
  • Generating grievance drafts
  • Helping users who may not be comfortable with formal government language
The result is a hybrid architecture:
1
2
3
4
5
6
7
8
9
10
Structured Data + Deterministic Rules
│
▼
Reliable Decision Logic
│
▼
Generative AI Assistance
│
▼
Human-friendly Response
This distinction was one of the biggest design lessons of the project.

Python AI Service

The AI functionality lives in a separate Python/FastAPI service. Python was a natural fit because of its ecosystem for machine learning and language processing.
The Go backend calls this service whenever an AI operation is needed. During grievance generation, for example:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
User
│
▼
Go Backend
├── Load user profile
├── Load scheme information
└── Load responsible department
│
▼
Prepare structured AI request
│
▼
Python / FastAPI
│
▼
AI model
│
▼
Generated grievance
Go stays responsible for application state and business logic, while the Python service focuses on AI-specific processing.

Where AWS Comes In

AWS was a major part of Sahayak because we wanted to explore how cloud services could support an application involving AI, speech, document processing, and accessibility. We used different AWS services for different parts of the system rather than forcing every feature through a single model.

Amazon Bedrock

Amazon Bedrock is the foundation for our generative AI functionality. We use foundation models through Bedrock for tasks such as generating grievance drafts and supporting natural-language interactions.
The model receives structured information like this:
1
2
3
4
5
Scheme: PM SVANidhi
Department: Ministry of Housing and Urban Affairs
User: Street vendor
Problem: Application submitted two months ago,
but benefit has not been received.
It turns that into a properly structured grievance while following constraints that prevent it from inventing missing information. The application supplies the known scheme and department details explicitly instead of asking the model to guess them.

Amazon Transcribe

Sahayak is designed with accessibility in mind. For users who find typing difficult, speech can be converted to text using Amazon Transcribe.
1
2
3
4
5
6
7
8
9
10
User speaks
│
▼
Amazon Transcribe
│
▼
Text
│
▼
Sahayak processing
This makes natural-language interaction possible without requiring users to type long descriptions.

Amazon Polly

The reverse direction is just as useful. Amazon Polly converts generated text into speech, so Sahayak can respond by voice instead of expecting users to read everything on screen.
Together, Transcribe and Polly form a speech-based interaction layer:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Voice Input
│
▼
Transcribe
│
▼
Sahayak / AI
│
▼
Response
│
▼
Polly
│
▼
Voice Output
This speaks directly to the problem we set out to solve: reducing the digital and literacy barriers around accessing welfare information.

Amazon Textract

Government applications often involve documents. Amazon Textract extracts text and structured information from uploaded documents, giving Sahayak a foundation for document-assisted workflows in which users don't have to type every detail manually.
1
2
3
4
5
6
7
8
9
10
Document
│
▼
Amazon Textract
│
▼
Extracted information
│
▼
Sahayak processing

Cedar Authorization

Security was another important part of Sahayak, and authentication and authorization are different problems.
  • Authentication answers: Who is this user?
  • Authorization answers: What is this user allowed to do?
We use JWT-based authentication to establish identity. For authorization, we integrated Cedar, a policy-based authorization system.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Request
│
▼
JWT Authentication
│
▼
Authenticated User
│
▼
Cedar Policy Evaluation
│
┌─────┴─────┐
│ │
ALLOW DENY
│ │
▼ ▼
Handler 403
This keeps authorization policies separate from application code. Instead of scattering ownership checks throughout handlers, Cedar policies describe which users may perform which actions on which resources. It also gives the authorization layer room to evolve as the application grows.

Grievance Generation

One of Sahayak's most practical features is grievance assistance. Suppose a user says:
I submitted my application two months ago with all required documents, but I have not received the disbursement or status update.
Rather than expecting the user to know how to write a formal government complaint, Sahayak prepares a structured grievance.
The system does not send the user's sentence straight to an LLM. The Go backend first assembles the context:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
User Profile
+
Scheme Information
+
Department
+
User's Problem
│
▼
Structured AI Request
│
▼
Python / FastAPI
│
▼
Amazon Bedrock
│
▼
Grievance Draft
We also added explicit prompting rules so the AI doesn't invent details such as application numbers, dates, payment references, Aadhaar numbers, or portal statuses. A polished-looking response is useless if it contains fabricated facts.

Why We Used Multiple Backends

At first glance, having Go, Java, and Python services may seem unnecessarily complex, but each one has a specific responsibility.
Go: application and business logic
  • Authentication
  • Profiles
  • Eligibility
  • Grievances
  • APIs
  • Database access
Java: scheme data and rule-related processing
  • Scheme ingestion
  • Scheme knowledge
  • Rule and data processing
Python: AI functionality
  • Natural-language processing
  • AI orchestration
  • AI-generated content
This separation also let different team members work independently without everything depending on a single codebase.

A Complete Example

Consider a street vendor from Maharashtra who wants to know which government schemes may apply to them.
  1. The user creates an account.
  2. Profile information is collected.
  3. Sahayak retrieves relevant schemes.
  4. Structured rules evaluate eligibility.
  5. Sahayak presents the matching schemes.
  6. The user selects a scheme.
  7. Sahayak explains the scheme.
  8. The user reports a problem.
  9. The Go backend enriches the request.
  10. The Python AI service processes it.
  11. Amazon Bedrock generates a draft.
  12. The user receives a structured grievance.
The user never needs to understand the underlying services. That complexity stays behind the interface.

Challenges We Faced

Building Sahayak under hackathon constraints forced several practical engineering decisions.

1. Separating AI from business logic

Early on, we had to decide what deterministic code should handle and what AI should handle. We learned that AI should complement the application's business logic, not replace it.

2. Keeping AI grounded

A generative model can produce convincing text even when information is missing. We passed verified scheme and department information to the AI explicitly and instructed it not to fabricate unknown details.

3. Coordinating multiple services

With Go, Java, Python, React, PostgreSQL, AWS services, and Cedar all involved, service boundaries mattered. Clear responsibilities let us work in parallel without every developer modifying the same part of the system.

4. Building under time constraints

As a hackathon project, Sahayak required us to prioritize functionality over building an unnecessarily large system. We got a working end-to-end flow first and improved individual components afterward.

What We Learned

Sahayak was more than an attempt to build an AI application. It showed us how different engineering disciplines fit together in a real system. We worked with:
  • Go backend development
  • PostgreSQL and SQL-based data modeling
  • Microservice-style architecture
  • Python/FastAPI
  • Generative AI
  • Amazon Bedrock, Transcribe, Polly, and Textract
  • Cedar authorization
  • JWT authentication
  • API design
  • Deterministic rule evaluation
  • AI safety and grounding
The biggest lesson was that building an AI-powered product is not just about connecting an LLM to an API. The surrounding system matters just as much: data, authorization, validation, business rules, service boundaries, and user experience.

Final Thoughts

Sahayak started with a simple question:
Can technology make government welfare information easier to understand and act upon?
Our approach combined structured scheme information with deterministic eligibility logic, generative AI, voice capabilities, document processing, and policy-based authorization. AWS provided the cloud and AI building blocks, while Go, Python, PostgreSQL, React, and Cedar formed the application architecture around them.
The result is a system designed not just to answer questions, but to guide a user from one step to the next:
1
2
3
4
5
6
7
8
9
10
11
12
13
"I don't know which scheme applies to me."
│
▼
"Here are relevant schemes."
│
▼
"Here is my eligibility."
│
▼
"I have a problem with my application."
│
▼
"Here is a structured grievance draft."
That is the idea behind Sahayak: a digital assistant for navigating government welfare schemes.
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article