Inspiration

I’ve been obsessed with building predictive systems for years. That obsession led to a research partnership with the University of Cambridge, focused on temporal reasoning — understanding how systems fail over time, not just at a single moment.

Over the last few months, that work became field-driven. I spent time embedded inside the UK rail network to understand why signalling issues have contributed to over £1 billion in fines in the last five years.

What I found wasn’t a lack of alerts — it was the opposite.

In a single control area, engineers can face hundreds of simultaneous signalling alerts, all competing for attention. The hardest problem isn’t detection, it’s prioritisation. Choosing which issues actually matter, under time pressure, with safety on the line.

Those decisions are still made using:

  • Spreadsheets
  • Emails
  • Paper records
  • Tribal knowledge built up over decades

The most important context lives in Word documents, inboxes, and shared drives — fragmented, siloed, and impossible to reason over at scale.

This problem is personal. My father has worked in rail signalling engineering for 35 years, and I’ve seen first-hand how much critical knowledge never makes it into a database, yet quietly shapes every operational decision.

So I built Signal-OS.

What it does

Signal-OS helps rail teams prioritise signalling risk.

It unifies unstructured legacy data into a single contextual view of each asset and uses probabilistic reasoning to assess which assets are most likely to fail — and why.

Instead of adding more alerts, Signal-OS:

  • Brings historical context into decision-making
  • Connects today’s alerts with long-term patterns
  • Explains risk in plain engineering language
  • Helps teams choose which problems to act on first

This is about better decisions under pressure, not replacing existing systems.

How we built it

Signal-OS is designed as a reasoning layer that sits on top of existing rail systems.

  • Data sources (simulated for the hackathon) represent files, emails, incident logs, and maintenance records. These are intentionally messy to reflect real-world conditions.

  • Gemini 3 processes unstructured documents into evidence while preserving timelines, domain language, and uncertainty.

  • A probabilistic reasoning layer synthesises years of context to infer risk and surface the most relevant contributing factors.

Without a reasoning-capable model, this problem collapses into brittle rules or shallow similarity search, neither can handle decades of contradictory, human-written engineering knowledge.

The ingestion layer is modular by design. In production, simulated connectors are replaced with live systems without changing the reasoning core.

Challenges we ran into

  • Legacy records frequently contradict each other or describe the same issue differently
  • Avoiding false confidence in a safety-critical environment
  • Reasoning over long, unstructured histories without losing signal
  • Demonstrating realism without direct access to live operational data

These challenges directly shaped the system’s focus on transparency and uncertainty-aware reasoning.

Accomplishments that we're proud of

  • Reducing alert overload rather than adding to it

  • Surfacing meaningful risk even when recent alerts look routine

  • Producing explanations engineers can interrogate and trust

  • Designing a production-ready architecture validated through early industry engagement

We have a LOI from Network rail and have been asked to begin integrating live data in the next few weeks as we move towards a pilot deployment.

What we learned

  • Most rail failures aren’t caused by missing data, they’re caused by missing context

  • Legacy documentation is one of the most underused assets in critical infrastructure

  • Reasoning-capable models outperform traditional pipelines in ambiguous environments

  • Trust and explainability matter more than raw accuracy in safety-critical systems

What's next for Signal-OS

  • Integrating live alert, telemetry, and document systems

  • Running a real-world pilot with operational data

  • Refining prioritisation logic with direct engineer feedback

  • Expanding to other safety-critical infrastructure domains

With over £1 billion in rail-related fines in the UK over the last five years, better prioritisation isn’t just a technical challenge, it’s an operational and economic necessity.

Built With

Share this project:

Updates