Al-Powered Automatic Block Planning to Maximize Asset Availability for Train Operations on Indian Railways

The receipts 🧾

Every red flag on this statement, in full. These are the four places it bites.

1. Exhibit A

   TMS, SMMS, TDMS, COA and BDMS are all internal Indian Railways systems with no external access, so the defect and overdue-maintenance backlog is entirely fabricated by you and you must say so rather than let it be discovered

2. It gets worse

   The constraints that make a block plan legal — minimum block duration, caution order implications, section-wise restrictions, crew rest — are not in the statement and getting them wrong makes an elegant schedule operationally impossible

3. Still reading?

   A railway judge will interrogate the realism of your synthetic demand distribution, so derive it from published defect and maintenance-frequency norms rather than from a uniform random draw

4. And the finisher

   Optimisation results are unphotogenic; a team that solves the problem beautifully and presents it as a table of numbers will lose to a worse solution with a better interface

The damage report 📉

Every score this statement earned, and what each one actually costs you.

• Feasibility

  3/5

  Buildable. Not comfortably. There is a week in here you have not planned for yet.

  Half the input is genuinely available — the passenger timetable is published and gives you real corridor occupancy to schedule against — but the maintenance demand side lives in TMS, SMMS and TDMS, which are internal Indian Railways systems with no external access, so the defect backlog has to be synthesised.

• Innovation scope

  4/5

  There is something genuinely new here. Do not bury it under another dashboard.

  The statement defines the objective and the inputs but says nothing about method, so how you formulate the problem — constraint programming, mixed integer optimisation, metaheuristics or a learned policy — and how you encode multi-department co-location are entirely your design decisions.

• Clarity

  4/5

  The ask is unambiguous, which quietly removes your favourite excuse.

  Unusually crisp for a railway statement: it names the source systems, the three departments, the two planning horizons and a single unambiguous objective in maximising asset availability, though it never specifies the constraints that make a block plan legal, which you will have to research.

• Acceptance potential

  4/5

  Strong footing before you have written a line. Try not to waste it.

  A properly constrained optimisation problem with a single measurable objective is rare and defensible at a hackathon, half the input data is genuinely real, and railway maintenance scheduling is unglamorous enough that very few teams will pick it.

• Effort

  Heavy

  Heavy. Somebody on this team is not sleeping in week three. Pick who, on purpose.

  Building a defensible synthetic maintenance backlog, extracting corridor availability from the real timetable, formulating and tuning the optimisation, and building a planner-facing interface with a comparison baseline is four workstreams where the constraint modelling will consume more time than the solver.

• Demo-ability

  Medium

  Demoable, if you rehearse it. Nobody rehearses it.

  A before-and-after Gantt with a downtime figure attached is genuinely persuasive to anyone who understands railway operations, but it is charts rather than motion, so the framing has to carry the impact for a general judge.

• Data

  None supplied

  No dataset comes with this one, so every accuracy figure you quote is a number about labels you invented.

  Nothing is provided with the statement. You are sourcing, cleaning and labelling it yourself, and that work is invisible in the demo but very visible in the questions.

The demo they will have already seen 🪞

Somewhere around 250–500 teams are heading here, and the description is doing the choosing for most of them. They will read the same brief, reach the same architecture, and build a version of the same demo you are planning. Being correct is the floor. If your five minutes could be swapped with the team before you and nobody in the room would notice, you have not picked badly — you have built predictably, which costs exactly the same and hurts more.

What survives 🛡️

The ground worth standing on when the questions start.

• This is a real optimisation problem with a genuine objective function, so you can prove improvement numerically against a baseline instead of claiming it — which almost no AI-flavoured submission at a hackathon can do
• The published passenger timetable is real, public data, so your corridor availability constraints are grounded even where the maintenance demand is synthetic
• Railway operations research attracts very few student teams, so the field for this statement will be thin and a competent formulation stands out