Â
1. The Problem, In One Paragraph
Indian Railways has 3 departments — Engineering (track), S&T (Signal & Telecom), and TRD (Traction/Electric) — that each independently raise requests for "blocks" (scheduled shutdown windows on a track section so maintenance can happen safely). These requests currently get approved manually, one at a time, department by department, with no system that looks across all pending maintenance needs and decides what should actually be prioritized and scheduled when. PS 26027 asks us to build the AI layer that does exactly that: take in maintenance needs + track/traffic availability, and auto-generate optimized weekly/monthly block schedules.
2. What Already Exists (so we know exactly what NOT to rebuild)
We found and read the actual official documents — not blog posts, real Railway Board / CRIS letters and manuals:
- BDMS (Block & Disconnection Management System) — built by CRIS, mandated by Railway Board (letter dated 30.09.2025), rolled out nationally starting late 2025. It's a digital workflow tool: a department raises a block demand → sends to TPC/CTPC → sent to COA for approval → approved/sanctioned → granted → work happens → returned → closed.
- Confirmed from the actual user manual: this whole pipeline is 100% manual, human-decided at every step. No prioritization scoring, no auto-scheduling, no defect-severity input anywhere in the block demand form itself.
- Our gap, confirmed not invented: BDMS = the plumbing (digitized requesting + approval). PS 26027 wants = the missing brain (deciding what to prioritize and how to schedule it intelligently). This is now our core, evidence-backed pitch line.
3. Domain Knowledge We've Locked Down (from official manuals)
a) Block duration rules (real, numeric, from IRTMM Ch.3 & Ch.5)
- Single line section: 1 block of 4+ hours OR 2 blocks of 2.5 hours (or minimum 2 hours in exceptional cases)
- Double line section: similar options, per line
- Specific machines have their own minimums: Ballast Cleaning Machine (BCM) needs min. 4 hrs, Portal Cranes (PQRS) need min. 2.5 hrs
b) Defect severity — huge finding, department-by-department:
- Engineering/Track (USFD Manual): HAS a real formal severity system —
- IMR (Imminent) = urgent: 30kmph speed restriction imposed immediately + rail replaced within 3 days
- OBS (Observation) = lower priority: fish-plate protection within 3 days, monitored, no speed restriction
- Similar IMRW/OBSW/DFWO/DFWR system for welds
- This gives us a real, citable severity scale for one of our three departments.
- S&T/Signal (Signal Engineering Manual Ch.11): Has NO formal severity scale — just binary: "maintainer can fix it himself" vs. "beyond his competence, escalate to senior." Also still uses a paper form (Form S&T/DN) requiring physical signatures — least digitized of the three departments.
- TRD/Traction (Electrical): Still an open gap — nothing found yet on formal severity classification here. Flagged for further search.
Why this matters: the 3 departments aren't just siloed from each other — they're at genuinely different levels of formality AND digitization. Track has a rigorous scale, Signal has none, and this inconsistency itself is a real insight for our pitch: "Our system standardizes prioritization consistently across departments that currently don't even use the same rigor of severity judgment."
c) Planning happens across THREE time horizons (not just one), all confirmed from official sources:
- Annual (IRTMM Ch.5): Divisions submit requirement plans by 30 Sept → draft deployment plan by 31 Jan → finalized plan by 31 March, effective from April.
- Weekly/Rolling (BDMS reports): There's an official "Rolling Block Program" report — Railway Board mandates its use, but nothing currently generates it — humans plan it with spreadsheets.
- Same-day (S&T Manual): Legally, a maintainer can request disconnection the same afternoon via a signed paper form — no minimum notice period required.
Why this matters: departments aren't just competing for the same time slot — they're operating on fundamentally different planning clocks, which is a root cause of coordination failure that most competing teams won't have found, since it requires reading multiple manuals against each other.
d) Why departments actually conflict (from IRTMM Ch.3, ~12 citable clauses)
It's not "two people booked the same meeting room." It's that certain work legally requires multiple departments to show up in the same window (e.g., tamping near S&T gear requires S&T staff present), but nothing in the current system schedules that coordination — it relies on humans remembering to tag it. BDMS's own "Shadow & Integrated Block" feature exists specifically to let departments manually tag related blocks — but it's a manual tagging feature, not automatic conflict resolution. BDMS even has a built-in report called "Integrated Blocks – No Associated Block Demanded" — meaning Railways themselves track and measure this exact failure pattern happening in real operations.
e) Additional real constraints we now know about
- Machine scarcity: machines like BCM can be shared across railways (Inter-Railway Deployment, needs Railway Board approval) — meaning block planning is also resource-constrained, not just time-constrained.
- Seasonal restrictions: "working season" is an official planning factor (heavy machine work isn't done in monsoon, etc.)
- Preventive maintenance cycles: e.g., PSC sleeper tamping required once every 2 years or 100 GMT of traffic, whichever comes first — gives us realistic grounds for generating preventive (not just reactive) maintenance defects.
4. The Dataset Plan — 9 Things We Need, What Each Does, and Where It Comes From
# | Dataset | What it does in our system | Source |
1 | Train timetable | Tells the AI when a section is free enough to block. Generates the candidate time windows. | Find real (partial) + synthesize rest |
2a | Section/corridor master data | Defines where blocks happen — real section names, lines, electrification. Static reference data. | Find real (we have BDMS screenshots as a schema reference) + synthesize |
2b | Conflict/adjacency rules | Logic for which blocks physically clash (e.g., UP FAST block ≠DN SLOW block). | We build this ourselves — it's logic, not a dataset |
3 | Maintenance tasks & defects | The actual work queue our AI ranks and schedules. Core input. | Synthesize, grounded in USFD severity system + domain input |
4 | Historical block records | Baseline "before AI" data — demanded vs. granted vs. spilled-over blocks, for our impact comparison. | Synthesize only — real BDMS operational data isn't public, but we have the real field schema from the manual to build it realistically |
5 | Goods/freight forecast | Explicitly named in the PS text — freight paths eat into usable block windows. | Find real (partial) + synthesize rest |
6 | National statistics | Pitch-deck numbers only (e.g., "X km of track"). Not used by the actual AI engine. | Find real, for pitch only |
7 | Machine/crew resource pool (added) | Tracks which maintenance machines (BCM, tamper, PQRS etc.) are actually available when — prevents the AI from scheduling 3 jobs needing the same machine at once. | Synthesize, grounded in real IRTMM machine types & minimum block durations |
8 | Pre-committed corridor block calendar (added) | Some block windows are already pre-approved as standing/recurring (per BDMS's real "BlockCorridor" table) — separate from the general train timetable. | Synthesize, grounded in real BDMS screenshot structure |
9 | Seasonal/working-season restrictions (added) | Flags months where certain heavy machine work isn't done (e.g., monsoon) — makes our monthly-horizon planning realistic. | Synthesize, small dataset, grounded in IRTMM mention |
Key principle to remember: items 4, 7, 8, 9 will never be "found" online — they don't exist publicly. We build them ourselves, but grounded in real official schemas and rules we've already sourced — so they're realistic and defensible, not arbitrary guesses.
5. What's Still Open / Left To Do
- TRD/Traction severity classification — still unfound, one more targeted search needed.
- Kaggle / Hugging Face / data.gov.in check — quick search for any existing public datasets (train timetables, defect data) we could reuse instead of building from scratch — not yet done.
- Pick the actual division/section our whole project will be based on — decision needed, not research.
- Academic literature check (optional, adds credibility to our pitch/report).
6. Bottom Line for the Team
We are not guessing that a gap exists — we have read the actual government documents and confirmed it, with citations. BDMS solved the "digitize the request and approval" problem. It does not solve "decide what's actually urgent and schedule it optimally" — and we have proof of that from the real user manual, not assumption. We also now have real numeric rules (block durations, severity classifications, planning calendars) to make our synthetic data and our AI logic genuinely grounded instead of made up. The next step is finalizing the 9 datasets above and picking our target division, then we start building.