Project Documentation

RailBuD

Smart Multi-Route Railway Planner for India

"When direct trains show 'Not Available', we show you the way."

Version 1.0
Prepared by: Founder
Last Updated: 2025
Purpose: Step-by-step travel planning for Indian Railways when direct trains show "Not Available".

Table of Contents

Part 1

Project Overview

01

Introduction

Most people search trains from Point A → Point B (example: Bhopal to Satna). If no seats are available or the train has already left, the apps say:

"Not Available"
"Train Departed"
"No more booking"

But in reality, the same route is often possible if the passenger breaks the journey:

Two-stop route:
A C B
Multi-stop route:
A D E B

Key Insight

These "hidden routes" are not shown in any railway app today. Passengers are left on their own to figure out alternatives.

Our Mission

Build a system that automatically finds alternate multi-train routes, predicts connection reliability, shows hidden seat availability, and provides backup plans.

02

Problem Statement

Why People Get Stuck

1

Direct trains show no availability.

2

The app does not show trains that become available if you change the boarding station.

3

Travellers don't know intermediate stations where seats may exist.

4

They don't know delay patterns, so they fear missing the next train.

5

They have no backup route if the first connection fails.

6

They don't understand chart-preparation zones and TTE risk.

The Result

Wasted time
Expensive tatkal
Unnecessary cancellations
Standing travel
Missed easy routes
Our system solves all of this.
03

Goals of the Product

Help passengers travel even when IRCTC shows no direct availability by:

Discovering Multi-Train Routes

Find all possible travel combinations using intermediate stations.

Showing Hidden Seat Availability

Reveal seats available on segments that IRCTC hides in direct search.

Predicting Delay Impact

Calculate if connecting trains can be caught based on historical delays.

Suggesting Backup Options

Provide alternative routes if primary connection fails.

Showing Fare Comparisons

Compare costs between different route options.

Highlighting TTE Zones

Show chart preparation status and checking risk areas.

"If the main route is full, the app will show how to still reach your destination using smart route combinations."

04

Target Users

Students
Daily Travelers
Last-minute Passengers
WL/Tatkal Failures
Emergency Travelers
Tier-2/Tier-3 City Passengers

Important Note

The product is not for ticketing. It is for planning smarter railway travel.

05

Core Features Overview (MVP)

The MVP includes six core features that work together to provide intelligent route planning:

Multi-Route Search Engine

Finds all possible travel combinations through intermediate stations.

View Details

Hidden Seat Finder

Discovers available seats on segments hidden from direct searches.

View Details

Delay Prediction Engine

Predicts connection safety based on historical delay patterns.

View Details

Backup Route Generator

Provides alternative options if primary connection fails.

View Details

Fare Calculator

Calculates segment fares and compares total journey costs.

View Details

TTE Zone Indicator

Shows chart status and TTE checking risk levels.

View Details
Part 2

Detailed Feature Requirements

For Developers & Designers

06

Onboarding & Basic Input Flow

6.1 Home Screen

User can enter:

From Station

Text input with autocomplete

To Station

Text input with autocomplete

Date of Journey

Calendar picker

Requirements

  • Station autocomplete using Indian Railways station list
  • Validation: From ≠ To
  • Past dates disabled

Output

Passes inputs to Multi-Route Engine

07

Multi-Route Search Engine

Core Feature

Core of the Product

This is the main feature. It finds all possible travel combinations when direct trains are unavailable.

7.1 Data Needed

List of trains operating between any two stations
Each train's route (station sequence)
Scheduled arrival/departure times
Distance between stations
Travel time matrix

7.2 Logic Requirements

A

Identify All Possible Intermediate Stations

If user searches:

FROM = Bhopal (BPL) TO = Satna (STA)

System must automatically scan:

  • Direct route (if exists)
  • Major junctions on the corridor (Bina, Katni, Jabalpur, Maihar)
  • Minor stations along the tracks
  • Backtrack routes (e.g., Bhopal → Itarsi → Katni → Satna)

Output

A list of candidate intermediate stations.

B

Find All Trains Connecting Any Two Segments

Example segments:

Bhopal → Katni
Katni → Satna
Bhopal → Jabalpur → Satna

For each segment, fetch:

  • Trains running on that route
  • Their timings
  • Availability (from partner APIs or cached data)
C

Connect Trains Into Feasible Routes

Rules:
1

Train B must depart after Train A arrives

2

Minimum buffer: 15–30 min (adjustable based on delay prediction)

3

No unrealistic midnight waits unless user allows it

4

Maximum journey time limit (optional)

Output

All feasible route combinations with the following categories:

Best Route Fastest Route Cheapest Route Most Reliable Route
08

Hidden Seat Finder

Segment Availability Engine

This feature finds seats IRCTC doesn't show in direct search.

8.1 Requirements

A

For Every Valid Train Combination

Check seat availability for:

  • Full route (FROM → TO)
  • Segment 1 (FROM → MID)
  • Segment 2 (MID → TO)
B

Detect "Hidden Seats"

IF

Full route availability = 0

BUT

Segment availability > 0

THEN

Mark route as "Hidden Availability Found"

8.2 Output Format

Example Display
Direct Route
Bhopal → Rewa
0 seats
Segment Available
Katni → Rewa
56 seats in 3A
Recommendation: Break journey at Katni
09

Delay Prediction + Connection Safety Engine

Purpose: Predict if user will catch the connecting train.

9.1 Data Needed

Historical train delay data (past 30–180 days)
Average delay per station
Real-time delay (optional at MVP stage)

9.2 Logic Requirements

A

Predict Arrival Time Window

For each train:

Scheduled arrival = X
Average delay = D
Predicted Range = X + D(min) → X + D(max)
B

Compare With Next Train Departure

IF
NextTrain.departure > FirstTrain.arrival + buffer
THEN

Calculate safety status:

>85%
High Safety
60–85%
Medium Safety
<60%
Low Safety

9.3 Output

Example Display
82% Connection Safety

Based on last 30 days — Train A usually arrives at 02:50, connection at 04:10

10

Backup Route Generator

If the first connection fails, system must show alternatives.

10.1 Requirements

For each major intermediate station:

  • List next possible trains toward destination
  • Show earliest departure times
  • Show availability if possible
  • Include trains from nearby junctions

10.2 Example Output

Backup: If you miss Rewanchal at Katni, take Mahakoshal Express at 06:20 from Jabalpur.

Alternative: Passenger train at 07:45 from Katni to Satna — unreserved.

11

Fare Calculation Engine

11.1 Data Needed

Fare rules (base fare, distance, reservation charges)
Distance chart for Indian Railways

11.2 Requirements

A

For Each Segment

Calculate fare by class:

SL 3A 2A CC
B

For Entire Journey

Show:

  • Total fare
  • Fare vs direct train (if direct available)
  • Cheapest recommended route

11.3 Output Example

Fare Comparison Table
Route Fare
BPL → KMZ ₹340 (3A)
KMZ → STA ₹210 (3A)
Total ₹550
Direct (if exists) ₹780
Save ₹230 with multi-route option
12

Chart Status & TTE Zone Indicator

12.1 Data Needed

Chart preparation time (from partner API)
Boarding station
Intermediate station charting rules

12.2 Requirements

For each train segment, show:

  • Chart prepared vs not prepared
  • Probability of TTE checking
  • Risk Zone Tag: Low / Medium / High

12.3 Output Examples

Chart: Not Prepared

Risk of TTE check is low until Bina.

Low Risk
Chart: Prepared

Expect TTE checking from Katni onwards.

High Risk

Disclaimer

This feature is for awareness purposes only, not for encouraging misuse of railway services.

Part 3

Technical Specifications & Planning

13

UI/UX Requirements

13.1 Journey Result Screen

Must display in a clean vertical flow:

Recommended route
Alternate routes
Hidden seat information
Delay safety indicators
Backup options
Fare table
Risk indicators

13.2 Color System

Use intuitive colors for quick understanding:

Green Available / High safety
Yellow Medium safety / Caution
Red Low safety / Unavailable
Blue Information / Backup routes

Design Principle

Avoid clutter. Keep the interface simple and scannable.

14

Performance Requirements

4–7 seconds

Maximum result load time

Cache Common Routes

Delhi → Mumbai, etc.

Retry Logic

If external API fails

Graceful Fallback

Show partial data instead of error

15

Edge Cases to Handle

1

No route found

2

Only unreserved trains available

3

Night travel connections with >6 hour gaps

4

Multiple trains with same arrival times

5

Trains cancelled or diverted

6

API failures from data providers

7

Stations with limited connectivity

System should always provide one of:

  • Alternate date suggestion
  • Nearby station suggestion
  • Bus/auto fallback (Phase 2)
16

Data Requirements

Data Needed

  • Train schedules
  • Station routes
  • Seat availability (from partner APIs)
  • Live train status (NTES API)
  • Chart status
  • Fare rules
  • Delay history

Data Sources

  • Public datasets
  • Approved API providers
  • Direct partnerships
  • Historical data modeling

MVP Scope

The system does NOT need full IRCTC access at MVP stage.

17

Technical Architecture

The system is divided into three layers:

1

Data Layer

Collects schedules, routes, fares, availability, and delay data.

Train Schedules DB Route Maps API Connectors Cache Store
2

Logic Layer

The Brain
Finds alternate routes
Predicts delays
Calculates reliability
Matches connection timings
Highlights hidden seats
3

User Interface

Enter From → To
Select Date
Recommended travel plan
Backup routes
Fares and risks
18

Success Criteria

A user should be able to say:

"Even when direct trains were full, this app helped me reach my destination."

MVP Success Metrics

70–80%

Valid multi-train routes generated for India's major city pairs

60%+

Hidden seats detected correctly

±25 min

Delay prediction accuracy

Positive

User feedback indicates successful travel

Definition of Success

If the user safely completes their journey using a multi-train route suggested by the app, the system is successful.

19

Risks & Constraints

API Dependency

Reliance on third-party APIs (short-term)

Licensing

IRCTC licensing required for long-term scale

Data Quality

Delay prediction depends on data quality

Information Overload

Risk of overloading user with too much information

Design Imperative

Design must stay simple. Avoid complexity in user-facing interfaces.

20

Phase 2 Features

Future

Non-MVP features planned for future releases:

Real-time GPS train tracking
Offline mode
Crowd-sourced PNR predictions
"Smart Alerts" for delays, platform changes
Integration with auto/taxi for station connections
21

Future Vision

The App Evolves Into:

The most intelligent railway route planner in the country

A companion that guides passengers like Google Maps guides drivers

A platform that reduces railway congestion by distributing passenger load

A system that becomes smarter with every journey

Future Integrations

Bus backups
Taxi to nearby stations
Automatic ticket booking (after IRCTC approval)

Tone & Philosophy

The app should feel:

Helpful Smart Trustworthy Human Simple

"A local friend who knows all the train tricks."

23

Conclusion

This project solves a real, large-scale problem in Indian rail travel.

It turns a manual "hack" used by knowledgeable passengers into a proper automated system.

It helps people travel even when the situation looks impossible.

No existing app currently offers this level of intelligence.

This Document Provides:

What the product does
Why it is needed
How it will work
What data it requires

This is the foundation for the development team to start building the system.