btw: whatever we find from official documents/internet is completely legitimate and valuable, often even more citable than an informal chat, since we can point to it as "official source" in front of judges. Both are valid, we're not missing anything.
What is "synthetic data," in the simplest terms??
synthetic = dummy data we generate ourselves, BUT NOT random garbage. Here's the distinction that matters:
- Random fake data = just making up numbers with no logic. ❌
- Synthetic data (✅) = we write a script that generates fake records, but the script follows real rules we researched (e.g., "IMR defects must trigger a 30kmph speed restriction and 3-day deadline," "BCM blocks must be minimum 4 hours," "peak hours are 6-11am and 5-9pm"). So the individual records are fake, but the pattern/structure and logic they follow is real and defensible.
STEP 1: Lock the Geography:
What exactly it is:
This is the decision of where, physically, our entire project's data pretends to exist. Not a technical dataset - a scoping decision. Every other dataset (timetable, defects, block records, etc.) will be built around this one chosen stretch of track, so our project feels grounded in one real place instead of floating/generic.
What we were looking for:
One real, nameable, continuous stretch of Indian Railways track — real station names, on a real division — that's complex enough to make our scheduling problem genuinely interesting, but bounded enough to explain in one sentence on a slide.
How this helps the project:
Everything downstream depends on it. It's the "map" our AI operates on. Without this locked, we can't build dataset #1 (timetable) or #2a (section master data) - they'd have nowhere to attach to.
What we have: ✅
✅ We have this, fully decided: Central Railway, Mumbai Division - corridor =
CSMT–Kalyan–Igatpuri and Kalyan–Karjat (ghat sections included).
picture it like a tree branching, not a single road.
CSMT ──── Thane ──── Kalyan ──┬── Kasara ──── Igatpuri (branch 1: toward Nashik) │ └── Karjat ──── Lonavala (branch 2: toward Pune)
Resolving teammate's doubt as well about station/section/division hierarchy (division = the control authority level, block section = the atomic bookable unit, depots = execution jurisdiction — not tied to one "head station").
The hierarchy explained
Think of it like a postal address system - Zone → Division → Section → Block Section → individual asset. Each level is a smaller zoom-in.
Zone (e.g. Central Railway) └── Division (e.g. Mumbai Division) └── Section (a named stretch between two major stations, e.g. "CSTM–Kalyan") └── Block Section (the smallest atomic unit — the stretch between two consecutive signal/block stations within that section) └── Individual assets (a specific pole, a specific signal, each with their own asset ID)
Signal: 🟢 GREEN. This is fully locked, no ambiguity left, nothing to search further. Move on freely.
STEP 2: Find the answers to some Practical Questions:
What exactly it is:
.. see all the questions
What we were looking for:
answers to practical "how does this actually work" questions — severity classification, planning horizons, conflict causes — either from a person's real experience or from digging into official documents deeply enough to get the same answers.
Answer to those 4 Questions (Verified ✅):
Q | Signal | Verdict |
Q1 | What gets fixed first? | 🟢 Nobody decides. Three mechanisms run in parallel and none compares departments. Proven by absence across IRTMM + ACTM ×3 + SEM. |
Q2 | Formal severity classification? | 🟢 Track: YES, with statutory deadlines and location weighting. OHE: partial. S&T: none. Ideal outcome — real anchor + documented void. |
Q3 | Planning horizon? | 🟢 Four nested horizons with named deadlines, not three. |
Q4 | Cause of conflict? | 🟢 Seven root causes, each citable. Three of them nobody else will find. |
Signal: 🟢 GREEN, confirmed, upgraded from before. Nothing more needed here - genuinely closed.
STEP 4: Search for the technical/domain reference docs:
What exactly it is:
The official railway manuals and government documents that give us real rules, numbers, and classifications to ground our synthetic data and our AI's scoring logic in — instead of inventing arbitrary thresholds.
What we were looking for:
Real defect severity systems, real block/machine duration rules, real planning cycles, real evidence of the coordination gap — from RDSO/Railway Board/CRIS sources.
How this helps the project:
This is the backbone of our MCDA scoring formula, our synthetic defect generator's realism, and our entire pitch's credibility (citing real clause numbers instead of vague claims).
this is genuinely our strongest step! we’ve everything.
BDMS Rollout letter, BDMS User Manual, BDMS in COA doc, USFD Manual (RDSO 2012), Signal Engineering Manual II Ch.11, IRTMM Ch.3, IRTMM Ch.5, ACTM (AC Traction Manual, multiple volumes/chapters), TRD-specific formal severity manual, The actual "Rolling Block guidelines" circular
STEP 5: Academic literature (optional, credibility booster)
What exactly it is:
Checking if this exact problem (railway maintenance window/track possession scheduling) has been studied in academic Operations Research papers - not required for building the project, purely for adding "we did real literature review" credibility to your pitch deck/report.
What we were looking for:
1-2 relevant papers on
railway maintenance window scheduling optimization or track possession planning optimization, searched via Google Scholar.How this helps:
Zero technical function - this doesn't feed into any dataset or any code. JUST purely a pitch-polish item: citing a real paper in your deck makes you look more rigorous than 95% of other teams who won't bother.