Rajdhani Express · Synthetic
17:10 → 07:40 · 14h 30m
3A · Tatkal · 8 synthetic seats
₹1,850
BUILD WHAT MOVES INDIA · INDEPENDENT PROTOTYPE
Tell us where you're going.
We'll handle the translation.
Sugam is a natural-language railway booking prototype. Instead of forcing a citizen to translate a travel request into many fields, it lets them describe what they want in everyday language and turns that request into a structured, reviewable booking intent.
What Sugam is: an independent research prototype exploring simpler public-service interactions. What it is not: an official IRCTC product, a live booking agent, or a replacement for government authentication, payment or reservation systems.
✓ English + Hinglish✓ OpenAI-powered intent parsing✓ Synthetic workflow✓ No live booking
THE PROBLEM
Railway booking asks citizens to translate their intent into forms.
Problem statement: A citizen may know exactly where they want to go, when they want to travel, who is travelling and what class or quota they need, yet the digital booking journey can require that intent to be translated into platform-specific fields, choices and error-prone steps. Sugam investigates whether a conversational layer can reduce this translation burden while keeping the citizen in control and making the boundaries between AI, validation and official services explicit.
Interaction friction
Users must convert a natural travel intention into platform-specific fields, selections and steps.
Language & digital familiarity
Public digital services serve people with different levels of language, device and digital familiarity.
Time-sensitive journeys
Railway booking can involve availability, authentication, payment and error recovery where clarity matters.
Research hypothesis: If citizens can describe a booking request naturally and review a transparent structured intent before execution, the number of manual translation steps required from the citizen should decrease.
THE PRODUCT IDEA
Less translation. More intention.
Say what you want
Describe the journey naturally instead of translating it into many fields.
AI structures intent
OpenAI extracts route, date, quota, class and passenger information into structured data.
Code controls execution
Deterministic application logic validates the AI output before the synthetic workflow continues.
HACKATHON BRIEF
What the challenge asks for — and how Sugam responds.
Important: This section is a project-facing interpretation of the challenge brief shown in the official Build What Moves India page. The exact submission form and portal fields remain the source of truth.
1 · The challenge
The challenge is about building a meaningful product for real Indian users and improving an important citizen journey. A strong entry should focus on a clearly defined user problem rather than adding AI only as a submission requirement.
2 · What you are expected to build
- A working prototype built with Codex or meaningfully powered by an OpenAI model.
- A solution to one clearly defined user problem.
- A complete main journey that can be experienced from start to finish.
- An experience that is easier to understand or use than the current journey.
- A design suitable for real Indian users, including mobile users, slower connections and people with different levels of digital experience.
- Mock or synthetic data wherever personal information, payments, OTPs or government systems would normally be involved.
3 · What makes a strong build
A strong submission makes the following obvious:
- Who is facing the problem? Define the citizen/user clearly.
- What is difficult today? Explain the existing friction rather than assuming it.
- What did you change? Show the new interaction and why it is different.
- Why is your version better? Explain the measurable or observable improvement.
- What works today, and what is mocked? Separate working prototype behavior from dependencies that are simulated.
- How could it scale safely? Explain the path from prototype to a responsible production architecture.
- Show the complete citizen journey. A static design alone is not enough; interactions should work from beginning to end.
4 · What not to do
- Do not access, test or interfere with a live government system.
- Do not reverse-engineer private systems or use undocumented private APIs.
- Do not scrape personal or restricted information.
- Do not use real Aadhaar numbers, PAN details, passwords, OTPs, payment details, health information or other sensitive data.
- Do not present the prototype as an official government product.
- Do not use government logos in a way that suggests approval or partnership.
- Do not submit an old project with only small changes.
- Do not include code, assets or data you do not have permission to use.
5 · Submission checklist
- Use the same registered email address consistently across the hackathon process.
- If entering as a team of two, use your partner's registered email where the form asks for it; if solo, leave the partner field blank where instructed.
- Make sure every submitted link works without requesting access.
- Provide a working prototype link that reviewers can open and test.
- Clearly disclose mock data, simulated behavior and external dependencies.
- Include your problem statement, product explanation, research evidence and limitations so reviewers can understand the decisions behind the build.
- Check the official submission form for the exact final fields, file requirements and deadline before submitting.
6 · How builds will be judged
ProblemIs this a real and important user problem?
Working buildDoes the main journey actually work?
UsabilityIs the experience simpler, clearer and more accessible?
Product thinkingAre the choices thoughtful and well explained?
End-to-end thinkingDoes the solution address backend, infrastructure and process—not just the interface?
HonestyAre limitations, mock data and dependencies clearly disclosed?
7 · What happens next
The brief describes selection in two stages after the form closes, beginning with a shortlist of 250. Keep the same registered email throughout the process because the organizers use it to track an entry. Later stages are determined by the organizers.
RESEARCH PAPER
Evidence behind the product decision.
The accompanying research synthesis examines railway and IRCTC user experience, Indian e-government usability, conversational public-service interfaces, AI-assisted intent interpretation, and the safety boundaries required for a responsible prototype.
Understand the friction
Examine interaction complexity, accessibility, mobile readiness, citizen experience and the role of conversational interaction in public services.
Evidence synthesis
Secondary research across official documentation, HCI/NLP research and contextual public reporting, used to frame design hypotheses rather than claim a completed user trial.
AI should interpret, not control
The model can translate flexible language into structured intent, while deterministic application logic validates fields and controls execution.
Architecture principle: Citizen intent → AI-assisted interpretation → structured booking intent → user confirmation → deterministic validation → synthetic workflow.
Read the full research paper (PDF) →
LIMITATIONS & SAFETY
What this prototype can—and cannot—claim.
Research limitation
The research is primarily secondary research. The exact Sugam workflow has not yet been validated through a controlled study with a representative passenger population, so usability and accuracy claims remain hypotheses to test.
OpenAI API limitation
The live AI step depends on the project's OpenAI API key, API account configuration, available API credits and model/service availability. During development, the prototype may show an API quota or configuration error even when the website itself is deployed correctly. This is a dependency of the AI service, not evidence that the Netlify deployment failed.
Technical limitation
Network failures, invalid configuration, expired or unavailable credentials, rate limits and service-side errors can interrupt live parsing. The API key must remain server-side and must never be placed in browser code or exposed in screenshots.
Service limitation
Sugam does not claim to replace official authentication, availability, payment, reservation or government controls. Production integration would require authoritative service interfaces, security review, privacy controls, reliability testing and additional validation.
Prototype-data limitation
Train inventory, passenger records, seat allocation, payment and PNR generation are synthetic or simulated. The demo is designed to prove the citizen journey without touching a live railway or government system.
Model limitation
Natural-language models can misunderstand ambiguous dates, stations, passenger details or preferences. User confirmation and deterministic validation are therefore deliberate safety boundaries rather than optional UI steps.
Responsible-use boundary: SUGAM is an independent prototype for simplifying natural-language railway booking workflows. It is not an official IRCTC or government system and is not affiliated with IRCTC. It does not access, test, reverse-engineer or interfere with live government systems. No real Aadhaar, PAN, passwords, OTPs, payment credentials or production booking accounts are required.
Next evaluation: task-completion rate, time on task, interaction count, clarification rate, extraction accuracy, error recovery, perceived ease of use and accessibility across devices and levels of digital familiarity.
DEMO VIDEO
See SUGAM in action
A short walkthrough of the independent SUGAM prototype and its intended natural-language railway booking workflow.