'-- background thread -> child process -> OR-Tools solver

The solver runs in a separate process, so a native crash fails one plan run instead of the whole server. Only one solve runs at a time.

Interface

React 19, TypeScript, React Router, Recharts. A scroll-driven homepage (SVG and GSAP) shows the journey from request to publish. After login a short 3D welcome and a calm 3D railway background (three.js) play; both respect “reduce motion” and have an off switch or skip button. Times are shown in Asia/Kolkata straight from the API.

Deployment

Frontend on Vercel, backend on Render, database on Supabase PostgreSQL. Database migrations ran on Postgres, row-level security is on for every table, and the live plan run was checked end to end on Postgres.

Example result

One run on the synthetic week of 19 to 26 October 2026: 16 requests, 4 sections, 3 departments. The solver proved the integrated plan optimal.

	Independent	Integrated	Change
Closures	15	7	-53%
Block hours	35	24	-31%
Trains affected	56	12	-79%

Testing

622 backend tests and 184 frontend tests pass, plus a real-browser end-to-end check (headless Chrome) of the whole planner workflow, including the viewer and department roles.

Honest limits

• All data is synthetic (timetable, traffic, requests, ML training data). Nothing here controls trains, signals or power.
• The numbers above come from simulated data and say nothing about real railway performance.
• The full backend test suite runs on SQLite; Postgres was verified for migrations and a complete plan run, not for the whole suite.
• The solver is not yet split up for 200 or more requests.
• Not built yet: resources and power blocks, recording what actually happened, event streaming, and cancelling a running plan.

Future work

Real timetable and traffic data, using the overrun model in the planner, decomposition for large instances, power-block and resource constraints, and feeding back actual outcomes to improve the models.