Returning to Rail in the Age of Applied AI4

I’m returning to the rail industry at a time when artificial intelligence has moved from research labs and proofs of concept into everyday engineering practice.

That doesn’t mean rail suddenly needs “AI everywhere”. It means some long-standing problems — forecasting, optimisation, decision support, operational insight — are now genuinely addressable with techniques that are stable, explainable, and deployable in regulated environments.

The challenge is not capability. It’s application.

// /studio/schemas/blocks/codeBlock.ts
import {defineType, defineField} from 'sanity'

export const codeBlock = defineType({
  name: 'codeBlock',
  title: 'Code Block',
  type: 'object',
  fields: [
    defineField({
      name: 'language',
      title: 'Language',
      type: 'string',
      options: {
        list: [
          {title: 'JavaScript', value: 'javascript'},
          {title: 'TypeScript', value: 'typescript'},
          {title: 'JSON', value: 'json'},
          {title: 'Bash', value: 'bash'},
          {title: 'HTML', value: 'html'},
          {title: 'CSS', value: 'css'},
          {title: 'Python', value: 'python'},
          {title: 'Text', value: 'text'},
        ],
      },
      initialValue: 'text',
    }),
    defineField({
      name: 'code',
      title: 'Code',
      type: 'text',
      rows: 10,
      validation: (Rule) => Rule.required(),
    }),
    defineField({
      name: 'filename',
      title: 'Filename (optional)',
      type: 'string',
    }),
  ],
  preview: {
    select: {
      language: 'language',
      filename: 'filename',
      code: 'code',
    },
    prepare({language, filename, code}) {
      return {
        title: filename || 'Code Block',
        subtitle: language,
        media: '💻',
      }
    },
  },
})

// /studio/schemas/blocks/codeBlock.ts
import {defineType, defineField} from 'sanity'

export const codeBlock = defineType({
  name: 'codeBlock',
  title: 'Code Block',
  type: 'object',
  fields: [
    defineField({
      name: 'language',
      title: 'Language',
      type: 'string',
      options: {
        list: [
          {title: 'JavaScript', value: 'javascript'},
          {title: 'TypeScript', value: 'typescript'},
          {title: 'JSON', value: 'json'},
          {title: 'Bash', value: 'bash'},
          {title: 'HTML', value: 'html'},
          {title: 'CSS', value: 'css'},
          {title: 'Python', value: 'python'},
          {title: 'Text', value: 'text'},
        ],
      },
      initialValue: 'text',
    }),
    defineField({
      name: 'code',
      title: 'Code',
      type: 'text',
      rows: 10,
      validation: (Rule) => Rule.required(),
    }),
    defineField({
      name: 'filename',
      title: 'Filename (optional)',
      type: 'string',
    }),
  ],
  preview: {
    select: {
      language: 'language',
      filename: 'filename',
      code: 'code',
    },
    prepare({language, filename, code}) {
      return {
        title: filename || 'Code Block',
        subtitle: language,
        media: '💻',
      }
    },
  },
})

Rail is a systems problem first

Rail is a network of interdependent systems: infrastructure, rolling stock, signalling, timetables, control rooms, and people.

Any useful application of AI in this context has to:

• Respect existing operational constraints
• Integrate with legacy systems
• Support human decision-making rather than replace it
• Be observable, explainable, and maintainable

This is why “AI transformation” as a standalone goal rarely works in rail. The unit of value is the system, not the model.

What has changed recently

A few things are materially different compared to even five years ago:

• Data accessibility is better (not perfect, but better)
• Tooling for building and deploying models is far more mature
• Techniques like probabilistic forecasting, optimisation, and anomaly detection are well-understood
• Infrastructure for running this safely (cloud, edge, hybrid) is proven

The result is that we can now focus on useful problems instead of novelty.

Where I see real opportunity

In my experience, the most promising areas are not flashy:

• Decision support for controllers and planners
• Forecasting under uncertainty (not “perfect prediction”)
• Operational analytics that explain why, not just what
• Automation of low-risk, high-volume analysis tasks

These are incremental improvements that compound over time.

How I’m approaching this work

My approach is deliberately conservative:

1. Start with the operational problem, not the data
2. Understand how decisions are made today
3. Design systems that fit into existing workflows
4. Use AI where it provides clear leverage
5. Measure success in operational terms, not model metrics

This is less exciting than demos, but far more effective.

Closing

Rail doesn’t need hype. It needs thoughtful engineering, clear analysis, and systems-level thinking.

That’s the lens I’m bringing back with me.