The Swiss timetable is a constraint solver in a trench coat
Why scheduling Swiss trains is one of the hardest optimisation problems hiding in plain sight — and how the same PESP math pre-flights your construction site.
Trains in Switzerland run on time, and the reflex explanation — discipline, money, mountains — is wrong. The real engine is a piece of applied mathematics most passengers never see: the timetable itself is a solved constraint satisfaction problem, recomputed continuously across the whole network. As Saurabh Sharan put it in The Swiss Train Secret, what looks like national punctuality is really a system designed so that delays have nowhere to propagate.
Here is the system architecture behind the headline. Switzerland runs a Taktfahrplan — a clock-face timetable where lines repeat on fixed intervals (every 15, 30, or 60 minutes) and the major nodes — Zürich HB, Bern, Basel — are tuned so connecting trains arrive just before the half-hour and leave just after. That single design choice converts a continuous scheduling nightmare into a periodic one. Mathematically it is the Periodic Event Scheduling Problem (PESP): every event is a variable, every minimum headway and transfer window is a modular constraint, and the solver hunts for an assignment where no two trains want the same metre of track in the same minute.
←TODAY: Swiss rail moves ~1.3 million passengers a day on a network where a 2-minute slip at one node can be absorbed instead of cascading. →3012: Every dense city in the Zurich-3012 manifesto runs on periodic, self-healing schedules — for trains, for energy, for compute. Fulcrum: Resilience is not slack you buy later; it is a constraint you encode at design time, when the graph is still cheap to redraw.
The instructive part is the failure mode. When the constraints are violated, you do not get a slightly worse timetable — you get a network that stops. In June 2026 The Guardian reported Deutsche Bahn grinding to a standstill after an IT-maintenance snag took down core systems, stranding hundreds of thousands. As The Rail Agenda argues in its survey of rail’s digital layer, software now governs the operational core — fleet management, asset monitoring, the traffic data that safety and capacity literally depend on. That is a single point of failure with a national footprint. The lesson I keep relearning from the late 2070s: we never ran out of compute. We ran out of intact systems and people who remembered how the old one worked.
Atelier: The same PESP machinery runs under your construction programme. A site logistics plan — one tower crane, three pours, deliveries through a single gate — is a periodic scheduling problem with headways (concrete truck spacing) and shared resources (the gate, the crane hook). Model it as constraints, not as a Gantt bar you nudge by hand, and conflicts surface before the trucks are on the road.
This is also where a real digital twin earns its keep. As PAZ’s concept panel on engineering twins notes, a twin stops being a museum the moment it recommends an action under uncertainty — close this lane, re-tension that cable — rather than merely visualising telemetry. A live timetable solver fed by sensors is exactly that: a twin that tells the dispatcher what to do next.
Hack: This Hack teaches you to detect a track conflict the way a clock-face timetable does — with modular arithmetic. The MEDIUM is runnable Python; the DOMAIN is Math: periodic events on one shared resource, compared by their offset within the repeat period.
period = 30 # clock-face: every line repeats every 30 min
lines = {"IC1": 4, "IR70": 19, "S12": 4} # arrival offset (min) on one platform track
min_headway = 3
slots = sorted(lines.items(), key=lambda kv: kv[1])
for (a, ta), (b, tb) in zip(slots, slots[1:]):
gap = (tb - ta) % period
print(a, b, gap, "OK" if gap >= min_headway else "CONFLICT")
Run it: IC1 and S12 both land at offset 4 — instant CONFLICT. Swap the dict for crane-hook windows or pour times and the same five lines pre-flight your site logistics. First step to go further: pip install ortools and graduate the print loop into a real CP-SAT model that solves for offsets instead of merely checking them.
The move this week: pick one shared resource on your project — a gate, a riser, a server queue — write its real periodic constraints on paper, and find the third conflict you didn’t know you had. That exercise is the whole point.
PAZ Kaffi · multidisciplinary editorial, led by PAZ Academy