Building RailPulse AI: Deploying an Open-Source Railway Dispatch Agent with Gemma and Google Cloud Run

Thank you, @pengeszikra Really appreciate you reading and highlighting that point. In physical systems like railways, you simply cannot let an LLM have unchecked authority over safety-critical thresholds. Combining cognitive reasoning with deterministic code interlocks has to become standard practice if we want autonomous systems trusted in the real world. Thanks for the support!

by the way how did you got this subscription badge @pengeszikra

This is gold @dafili, thank you for such a sharp systems-engineering review! Both of those points hit right at the heart of real-world safety engineering:

1. Unit-bound types (km/h vs m/s): Passing raw floats is how Mars Climate Orbiter-style bugs happen. Wrapping telemetry fields in explicit unit-validated Pydantic types (or pint quantities) at the ingestion boundary so wind_speed_kmh rejects or converts raw m/s anemometer reads before enforce_guardrails ever runs is a must.
2. Binding the signed observation directly to the interlock: Instead of trusting parameters passed back through the agent loop, enforce_guardrails should pull the immutable, timestamped sensor struct (corridor_id, source_id, observed_at_utc) directly from the telemetry store and verify freshness inside the guardrail itself.

I love those two exact unit test assertions (speed=140, wind=70.6 -> 80 and stale_timestamp -> 0). I am going to add both of those directly into the repo's test suite!

I love how you phrased that @eye_java_420f1faa10ae8b86: "the guardrail stops trusting values and starts trusting (value, age) pairs."

In practice, a two-layer hybrid works best: per-sensor TTL in the backend interlock mapped to a single unified freshness state on the dispatcher UI.

At the ingestion and guardrail layer, a single global TTL breaks down quickly because different railway subsystems publish on very different cadences:

• Wayside interlocking & track-circuit signal state: event-driven / sub-second heartbeat (TTL ~ 2 to 3s)
• Locomotive GPS & axle-bearing thermal sensors: high-frequency telemetry (TTL ~ 10 to 15s, usually 2x to 3x the publish interval)
• Corridor weather / anemometer stations: slower polling (TTL ~ 60 to 120s)

If you used a 60s global TTL, a 10-second-old signal state would be dangerously stale; if you used a 3s global TTL, the wind sensor would constantly trip false-stale holds. So each sensor type carries its own max_age_s = k * publish_interval_s in the Python interlock, but if any safety-critical input exceeds its own TTL, the operator cockpit surfaces one clear, unambiguous banner (STALE TELEMETRY [WIND_SENSOR]: HOLDING AT RESTRICTIVE) so the dispatcher never has to do mental math across different sensor clocks during an emergency.

Spot on @alexshev! Showing the counterfactual ("which conflict this resolves, and which downstream train or siding window it displaces") is what separates a real decision-support cockpit from a black-box oracle.

In single-track or bottlenecked rail corridors, every recovery action is a trade-off: holding a freight consist at Siding B clears the block for an oncoming express, but pushes the freight crew closer to their statutory hours-of-service limit. Extending the RailDispatchAdvisory Pydantic schema with explicit resolved_conflicts, displaced_resources (for example, secondary delay minutes added to opposing traffic), and an uncertainty/confidence band gives the human dispatcher immediate situational awareness to accept or override the plan in seconds. Love that framing of using the model for triage rather than unchecked authority!

Really appreciate that @paullovelace Yes, hot-box (axle bearing temperature) detection belongs 100% inside the deterministic Python interlock right alongside the wind clamp and signal state, never left up to prompt instructions alone.

In rail operations, bearing temperature usually has two hard thresholds: an elevated warning band (for example, above 85°C where you clamp speed and route the train to the next siding for inspection) and a critical thermal threshold (above 105°C or a rapid delta spike compared to adjacent axles on the same bogie, which forces an immediate 0 km/h emergency stop to prevent axle seizure). Having Gemma summarize why the bearing is heating up alongside track gradient and load weight is super helpful for the human dispatcher, but the actual speed clamp has to live in deterministic code.

Great question @onelifevibe ! It actually caught the model multiple times during our stress testing before the DevFest Baku demo, and in a very revealing way.

Whenever we gave the scenario a severe schedule delay (for example, a passenger train running 25 minutes late with a tight single-track siding window ahead) and borderline high crosswinds (around 68 to 72 km/h), smaller quantized models would occasionally prioritize "making up schedule time" in their reasoning chain and propose 110 to 125 km/h while still acknowledging the wind in the text summary! That was our biggest "aha" moment during testing: an LLM can literally mention a hazard in its explanation while still outputting an unsafe numeric parameter in the JSON tool call. Watching the Python interlock catch that 120 km/h proposal and slam it down to 80 km/h in real time proved why you always need code enforcement sitting after the model.

Thank you @iictp! That is a great catch because in real SCADA and railway telemetry, dropped packets or stale sensor reads happen all the time, especially through mountain tunnels.

Holding the last advisory is actually dangerous if a train is entering a high-wind zone or approaching a signal change. In a production deployment, the interlock should treat stale telemetry as a degraded safety state rather than trusting the last cached number. Specifically, every telemetry payload carries a UTC timestamp, and if the delta between the current clock and the last sensor heartbeat exceeds the poll window (for example, 15 seconds), the interlock bypasses the LLM recommendation entirely, steps the speed target down to a conservative restricted-sight speed (or triggers a full hold depending on the block state), and flags a TELEMETRY_STALE warning on the operator cockpit. Never let the agent guess when the sensors go blind!

Spot on @devkursat , and I actually agree with you on the latency and abstraction tax! That is one of the main reasons we chose open-weight Gemma models for this architecture rather than locking into a proprietary cloud-only API.

When you own the weights, you can run the exact same Gemma model on bare-metal edge hardware at the wayside or locomotive level via vLLM or llama.cpp for deterministic sub-second latency, or inside a self-contained GPU container on Cloud Run when you want elastic central dispatch without managing Kubernetes clusters. The agent layer here is kept intentionally thin (just structured tool bindings + hard Python safety interlocks) so there are no multi-hop prompt chains adding unpredictable tail latency.