He Named the Railway Safety Protocol After Himself — Then the Accident Branch Required the Firmware Commit History Only She Had
He Named the Railway Safety Protocol After Himself — Then the Accident Investigation Branch Required the Firmware Commit History
Priya Nair was running scenario batch 37,000 to 38,000 when Amir asked why scenario 22,847 was flagged in the output log.
She said: “Pull up the route-logic trace for that scenario.”
He opened it on the adjacent terminal.
She said: “The failure window. Train A clears section B at timestamp 14.3 seconds. The signal logic releases the route-lock at 14.4 seconds. But the check sequence for section B runs at 14.1 seconds — before the clearance. At 14.1, section B shows occupied. The route-lock should hold. It doesn’t.”
Amir read the trace.
He said: “Because it checks at 14.1 but doesn’t act until 14.4?”
She said: “The check and the action are decoupled by 0.3 seconds. In the hardware cycle, 0.3 seconds is enough for a second route to be set before the lock engages. Two routes simultaneously set at speed. That’s the window.”
He said: “3 seconds.”
She said: “3 seconds between the first train’s clearance and the signal re-enabling. In any scenario where a second train is queued behind the first and the driver anticipates the signal, the window is live.”
He said: “How many scenarios triggered it?”
She said: “Fourteen. Out of 40,000. All in the same logical cluster — high-frequency service, same route-set pattern, driver anticipation model active.”
Amir wrote it down.
She had found scenario 22,847 on a Tuesday evening at 7:15 PM, two weeks into the simulation run.
She had been in the simulation room for nine hours.
She had been running scenarios in batches of 1,000 since 9 AM.
She had flagged the scenario and continued running.
She had not stopped to celebrate the find.
She had continued to batch 23,000 to confirm the cluster.
She had confirmed it by batch 25,000.
She had continued to batch 40,000 to be certain there were no other failure modes in the logic tree.
She had completed the full run in six weeks.
She had written the firmware patch in the three weeks after that.
The firmware patch was 187 committed changes to the East Midlands interlocking logic.
Every commit was signed: Priya Nair, UK-7741.
UK-7741 was her IRSE licensed developer certificate number.
She had received it in 2016 after passing the Institution of Railway Signal Engineers examination.
She was the only IRSE-licensed engineer on the East Midlands project team.
She had been the only one for eleven years.
She had the red signal flag in her jacket pocket.
She had carried it since the field inspection at the East Midlands junction site three years ago.
The flag was cotton, folded in quarters, standard railway lineside equipment.
She had used it for the sightline test that day — standing at the signal gantry and holding the flag at arm’s length to confirm the driver’s line of sight to the signal head.
The oil stain on one quarter was from that day.
She had put the flag back in her pocket.
She had not taken it out since.
She had carried it in the same jacket every working day.
—
The National Rail safety bulletin was published on the agency website on a Monday morning.
Priya read it on her phone at her desk at 10:30 AM.
She had known it was coming.
Derek Kellerman, Operations Manager, East Midlands Region, had told her the bulletin was being finalized two weeks before.
He had not shown her a draft.
She read the title: “Kellerman Protocol for Junction Interlocking Logic — A Risk Elimination Framework.”
She read the byline: Derek Kellerman, Operations Manager.
She scrolled to page 8.
Project team: Derek Kellerman, Operations Manager. Priya Nair, Signal Design Engineer.
She put her phone face-down on the desk.
She felt the folded flag in her jacket pocket.
She did not take it out.
She picked up her phone.
She read the rest of the bulletin.
The bulletin described the failure window.
It described the simulation methodology.
It described the firmware patch.
It described all of it accurately.
It described all of it without her name.
She finished reading.
She put the phone away.
She went back to her terminal.
—
The Before was three months earlier — the week after the final simulation results were delivered to Derek.
He had called her to his office.
He said: “Good solid work on the scenario run. We’ve got a watertight case for Network Rail now.”
She had said: “The failure window is in the batch 23 output — scenario 22,847. I’ve flagged it in the report.”
He had nodded.
He had said: “Exactly. We’ve got it documented.”
He had meant it as confirmation.
He had used “we.”
He had not said “you found it.”
He had said “we’ve got it documented” because the documentation was complete and the project was ready for Network Rail and that was the outcome he was managing toward.
He had used “we” because it was the correct pronoun for the team he managed.
She had heard it.
She had left his office.
She had gone back to the simulation room.
She had begun writing the firmware patch.
She had written the first commit that afternoon.
She had signed it: Priya Nair, UK-7741.
She had written 186 more.
She had signed all of them.
—
She opened the firmware commit log after reading the bulletin.
187 entries.
The first entry: 14:32 on a Tuesday in October. Priya Nair, UK-7741. Commit message: “Interlocking logic v2.0 — failure window patch, scenario cluster 22847-22860, route-lock synchronization fix.”
The last entry: 09:14 on a Friday in January. Priya Nair, UK-7741. Commit message: “Interlocking logic v2.13 — final compliance check, East Midlands junction, all 14 failure-mode scenarios clear.”
She scrolled through the log.
She did not annotate it.
She closed it.
She had the flag in her pocket.
She went back to work.
(Drop “PRIYA” in the comments if you want to read what happened when the accident investigation branch required the firmware commit history.) 👇
The railway safety conference was at the Birmingham NEC in February.
Derek was at the podium.
He was projecting the junction failure diagram from Priya’s simulation output — the route-lock timing chart she had built to illustrate the 3-second window.
Priya was in the third row.
She had the flag in her jacket pocket.
She had attended this conference to hear about a different paper — a presentation on platform detection logic at the 11 AM slot.
Derek’s presentation was at 9:30 AM.
She had arrived in time for it.
She was in the third row.
He said: “The Kellerman Protocol identifies what we termed the failure window — a timing gap in the route-lock sequence that, under specific service conditions, allows two conflicting routes to be simultaneously set. The protocol eliminates this window through a synchronisation fix in the interlocking firmware.”
He clicked to the next slide.
He said: “The discovery process involved extensive scenario modelling — over 40,000 simulated service scenarios, run through the East Midlands junction logic to surface the specific failure conditions.”
A delegate in the second row asked: “How long did the scenario run take?”
Derek said: “Several weeks. We committed significant resource to getting the modelling right.”
He moved to the next slide.
He described the firmware patch.
He described the route-lock synchronisation fix.
He described it in language that was close but not identical to the language in Priya’s commit messages.
He had read her commit messages.
He had read them in the project handover report she had written for Network Rail.
He had not written the commit messages.
He had read them and he was now saying something close to them in front of 200 delegates.
She was in the third row.
She had her conference programme.
She had underlined the 11 AM presentation.
She waited for 9:30 to finish.
—
The RAIB email arrived on a Thursday.
Subject: RAIL ACCIDENT INVESTIGATION BRANCH — EAST MIDLANDS INTERLOCKING LOGIC — FIRMWARE TRANSMISSION REQUEST.
She read it at her terminal at 8:45 AM.
The RAIB was investigating a signal failure at a separate junction in the East of England.
The failure had caused a near-miss — two trains on conflicting routes, stopped by automatic brake systems 180 metres short of the conflict zone.
The RAIB wanted to use the East Midlands interlocking firmware as a compliance reference — a verified example of correct fail-safe design.
The email said: “Transmission of classified safety-critical interlocking firmware requires authorization from the IRSE-licensed developer of record. Please confirm whether the originating developer is available to authorize the server release under their IRSE certificate.”
She read “IRSE-licensed developer of record.”
She knew what the server authorization portal required.
She had used the portal herself, twice, for test firmware releases during the implementation.
The portal required IRSE certificate authentication.
Derek’s credentials were management-level.
He was not IRSE licensed.
He could not authorize the transmission.
The firmware was signed to UK-7741.
She opened the commit log.
187 entries.
All UK-7741.
She closed it.
She did not forward the email to Derek.
She had a dataset from the new Tyne Valley junction assessment on her terminal.
She opened it.
She began reviewing the track geometry data.
She waited.
—
Derek read the RAIB email at 10:30 AM.
He read “IRSE-licensed developer of record.”
He was not concerned.
He had managed regulatory requests for 12 years.
He opened the National Rail server authorization portal.
He entered his management credentials.
He selected the East Midlands interlocking firmware package.
He clicked “Authorize External Transmission.”
The portal displayed: “Authorization failed. IRSE licensed engineer certificate required for safety-critical firmware transmission. Management credential level insufficient. Certificate required: IRSE developer of record for the specified firmware package.”
He read it.
He clicked back.
He looked up the server credential documentation.
The documentation said: “Safety-critical firmware may only be authorized for external transmission by the IRSE-licensed engineer who holds the originating development certificate for that firmware package.”
He looked up the originating certificate for the East Midlands firmware.
The system returned: “Certificate UK-7741 — Priya Nair, IRSE Chartered Engineer. Primary developer: East Midlands Interlocking Logic v2.0-v2.13. 187 commits.”
He sat with that for a moment.
He had approved the firmware.
He had approved it after she delivered the implementation report.
He had signed off the project as complete.
He had submitted the safety bulletin to National Rail.
He had called it the Kellerman Protocol.
He had called it that because he had managed the project that delivered it.
He had called it that because his name was on the submission.
He had been sitting with his name on the submission for eight months.
He looked at UK-7741.
He looked at 187 commits.
He had reviewed the monthly project reports she sent him.
He had reviewed the results.
He had understood the results as the output of the project he managed.
He had not understood whether finding a 3-second failure window in 40,000 simulated scenarios was something that happened inside a managed project or whether it was a thing that only happened because one specific person knew where to look.
He had not asked.
He had called it “good solid work.”
He had said “we’ve got it documented.”
He opened his email.
He typed: “RAIB need the interlocking firmware. Please authorize the server release under your IRSE credentials.”
He sent it.
—
She had read the RAIB certification requirement standing at her terminal.
She had read it twice.
She had read it a third time to confirm she had understood it correctly.
It was clear.
The originating developer.
The IRSE-licensed engineer who had produced the firmware.
That was her.
She had produced 187 commits.
She had produced them between October and January.
She had produced them alone, in the evenings and on weekends, because the implementation timeline was tight and the firmware needed to be production-ready before the Network Rail review in February.
She had worked on it in her office after Derek had gone home.
She had worked on it on Saturdays.
She had committed each change under UK-7741 because that was the standard.
Every commit had to be signed by the producing engineer.
That was the safety protocol.
That was how railway interlocking logic worked.
The signature was the chain of custody.
The signature was the proof of who had written the code and when.
The signature was what the RAIB was now asking for.
She had the signature.
She closed the commit log.
She opened the Tyne Valley dataset.
She had 40,000 scenarios to run.
She had not started yet.
She started now.
She read Derek’s email at 11:22 AM.
She had the Tyne Valley track geometry data on her screen.
She had been reviewing the survey report for 40 minutes.
She opened the firmware server portal.
She entered her IRSE certificate credentials: UK-7741.
The portal recognized her: “Priya Nair, IRSE Chartered Engineer, UK-7741. Primary developer: East Midlands Interlocking Logic v2.0-v2.13.”
She selected the firmware package.
She selected “Authorize External Transmission.”
She entered the RAIB access identifier from the email.
The portal requested confirmation: “You are authorizing external transmission of safety-critical firmware to: Rail Accident Investigation Branch, RAIB-2024-047. Authorization will be logged under: Priya Nair, UK-7741, firmware originator. Confirm?”
She confirmed.
The authorization was logged.
The RAIB server received the firmware package.
The access log read: “Authorized by: Priya Nair, IRSE UK-7741, firmware originator. East Midlands Interlocking Logic v2.0-v2.13. 187 commits transmitted.”
She closed the portal.
She went back to the Tyne Valley data.
—
RAIB Inspector Lena Holm received the firmware package at 11:47 AM.
She opened the commit history.
She went to the first commit.
She read: “Interlocking logic v2.0 — failure window patch, scenario cluster 22847-22860, route-lock synchronization fix. Certificate: UK-7741 — Priya Nair, IRSE.”
She went to commit 22.
She read: “Route-lock sequence timing — 0.3-second decoupling corrected. Secondary validation added at 14.1s check. Certificate: UK-7741.”
She went to commit 187.
She read: “Final compliance check — all 14 failure-mode scenarios clear. Interlocking logic v2.13 certified for East Midlands junction. Certificate: UK-7741 — Priya Nair, IRSE.”
She looked at the RAIB access log.
It said: firmware originator.
She sent a reply to Priya.
Subject: RAIB-2024-047 — EAST MIDLANDS FIRMWARE RECEIPT — DR. P. NAIR.
It said: “Ms. Nair — firmware received, 187 commits reviewed. The scenario 22,847 failure window identification is the key analytical finding of the East Midlands redesign. You will be cited as the signal logic author in the RAIB interim report. Please confirm your availability for the technical briefing scheduled for [date]. All technical questions at the briefing will be directed to you.”
Amir was at his desk to the left of Priya’s terminal.
He was reviewing a different set of simulation outputs — a draft scenario run for the Tyne Valley assessment.
He saw the RAIB reply land in Priya’s inbox.
He saw the subject line.
He saw “DR. P. NAIR.”
He said nothing.
He opened his engineering notebook.
He wrote, on a clean page: “UK-7741 — Priya Nair. RAIB-2024-047. Firmware originator. Signal logic author.”
He had been in the simulation room for all 40,000 scenarios.
He had his own copy of the batch session logs.
He had written “scenario 22,847” in three different engineering notebooks in the past year.
He said nothing.
He went back to his simulation outputs.
—
Derek called her at 1:45 PM.
He said: “RAIB are happy. Good outcome.”
She said: “The commit log is in their hands now.”
He said: “Yes. Good.” He paused. “Going forward, we should make sure attribution is clearer on this kind of work. The bulletin — I should have had your name more prominently in the byline.”
She said: “Yes.”
He waited.
She did not say anything else.
He said: “Was there anything else?”
She said: “No.”
He said: “Good work.”
She said: “Thank you.”
She hung up.
She went back to the Tyne Valley data.
—
The bulletin amendment arrived by email the following Wednesday.
Derek had requested it from the National Rail communications team.
The amended title was unchanged: “Kellerman Protocol for Junction Interlocking Logic.”
The authorship line now read: “Designed by Priya Nair, IRSE Chartered Engineer. Implementation managed by Derek Kellerman, Operations Manager.”
She read “designed by Priya Nair.”
She read “implementation managed by Derek Kellerman.”
She filed the amendment confirmation in the project folder.
She had the RAIB briefing in seven days.
She went back to the Tyne Valley data.
—
Derek had also, before sending the email, looked up what IRSE certification required.
He had looked it up because he had not known, until the portal told him, that the certificate was personal to the engineer.
He had thought of credentials in terms of organizational roles: project manager, engineer, director.
He had not thought of them in terms of what the individual engineer had done.
He had looked up the IRSE licensing framework.
It said: “IRSE licensed developer certificates are issued to individual engineers based on demonstrated competency in safety-critical signal engineering. The certificate number is unique to the holder and is embedded in all firmware commits made under that certificate. No organizational credential or management authorization can substitute for the individual certificate of the originating developer.”
He had read “no organizational credential can substitute.”
He had read “originating developer.”
He had sent her the email because there was no other available action.
He had sent it in 20 words: “RAIB need the interlocking firmware. Please authorize the server release under your IRSE credentials.”
He had not said: I looked up the licensing framework and understand why I cannot do this.
He had not said: The portal tells me the firmware is yours.
He had said: “RAIB need the firmware. Please authorize it.”
He had said it because it was what was needed and because she was the only person who could do it.
He had sent the email.
He had stared at the portal for a moment after.
He had reviewed the project in his head: the Network Rail meetings, the technical reviews, the management of the implementation schedule, the submission of the safety bulletin.
He had managed all of those things.
They were real.
They had been necessary.
He had needed to manage them.
But the firmware — 187 commits, UK-7741, scenario 22,847 — was not inside the things he had managed.
It was something she had done while he was managing.
He had known that.
He had called it “good solid work.”
He had not examined whether “good solid work” was the right description for finding a 3-second failure window in 40,000 scenarios.
He sent the email.
He looked at his desk.
He picked up his phone.
He put it back down.
He went back to his schedule.
The IRSE nomination letter arrived on a Friday morning.
It was from Derek.
The cover note said: “Please find attached my nomination for your IRSE Chartered Engineer recognition. The nomination cites the East Midlands junction redesign specifically. I’ve sent it to the IRSE board today. You should receive a copy from them directly within two weeks.”
She read the cover note.
She read the nomination letter.
The nomination described the failure window identification.
It described the 40,000-scenario simulation run.
It described the 187-commit firmware patch.
It described all of it under her name.
It said: “Ms. Nair identified a 3-second timing gap in the East Midlands interlocking logic through exhaustive scenario modelling and corrected it through a complete firmware redesign. This work directly prevented a multi-train collision scenario and represents the standard of individual engineering contribution that IRSE Chartered recognition is intended to acknowledge.”
She read “individual engineering contribution.”
She put the letter in her bag.
She had the RAIB briefing in three days.
—
The Tyne Valley junction assessment was a six-week contract.
The junction was in Northumberland.
The failure mode was different from East Midlands.
The East Midlands failure had been a route-lock timing issue.
The Tyne Valley issue was a track-circuit dead-section problem — a 40-metre section of rail where the detection system could lose a stationary train under specific weather conditions.
A different problem.
The same method: scenario modelling, failure mode analysis, firmware logic.
She had been at the junction site that morning for the field inspection.
The original bulletin was still on the National Rail website.
The amendment was alongside it.
Both files were available for download.
She had checked the download counter that morning on her phone before driving to the site.
The original: 3,400 downloads.
The amendment: 140 downloads.
The original would always have more downloads than the amendment.
The people who had already downloaded the original would not necessarily look for the correction.
She knew this.
She had checked the counter.
She had put her phone in her jacket pocket.
She had the flag in the same pocket.
She pulled the flag out.
She stood at the signal gantry.
The cotton was soft from three years of folding.
The oil stain on one quarter had faded to a pale brown that would not wash out.
She held the flag at arm’s length toward the signal head.
She confirmed the driver’s sightline was clear from the approach curve.
She noted the result in her field log.
She folded the flag back into quarters.
She put it in her pocket.
She walked back to the survey vehicle.
She opened her laptop.
She opened the Tyne Valley simulation environment.
She typed the first scenario parameter: track length, train weight, ambient temperature.
She set the scenario count: 40,000.
She started the run.
She went to the terminal.
She began the scenario modeling for the new junction.
—
The nomination letter also included the East Midlands simulation session logs as supporting evidence.
Derek had attached them.
They were her session logs — the daily batch reports, in her format, with her annotations in the margin.
She had sent them to him in the monthly project reports.
He had attached them to the nomination without comment.
The session logs showed: six weeks, 40,000 scenarios, one engineer, one terminal.
The IRSE board would read the session logs.
They would see her name on every batch report.
She had put the nomination letter in her bag.
She had the flag in her pocket.
She had driven to Northumberland for the site inspection.
She had stood at the signal gantry.
She had held the flag at arm’s length.
The sightline was clear.
The amended bulletin was on the National Rail website with 140 downloads against the original’s 3,400.
She had checked the counter.
She had folded the flag.
She had gone to the terminal.
She had the Tyne Valley data in front of her.
The track-circuit dead section was a 40-metre problem.
She had the sensor array data from the site survey.
She had the weather records for the past three winters.
She had the train weight distribution data for services through the junction.
She had everything she needed to build the failure model.
She had not yet run a single scenario.
She would run 40,000.
She would find what she was looking for when she found it.
She set the scenario parameters.
She started the run.
She had 40,000 scenarios ahead.
She did not know how long it would take.
She went to work.
The RAIB technical briefing was on a Tuesday.
She drove to the RAIB offices in Woking.
She had her engineering notebook and the printed commit history.
She had not brought Derek.
He had not been invited.
The RAIB had invited the IRSE-licensed developer of record.
She was the IRSE-licensed developer of record.
Inspector Holm ran the briefing.
There were six people in the room: Holm, two RAIB technical staff, a representative from Network Rail, and Priya.
Holm opened with: “We’re here to review the East Midlands interlocking logic as a compliance baseline for the East of England near-miss inquiry. Ms. Nair, your firmware is the reference implementation. We’ll be working through the commit history.”
They worked through the commit history.
Holm had questions about commits 22 through 45 — the route-lock synchronisation sequence.
Priya answered them.
Holm had questions about the failure mode cluster at scenarios 22,847 to 22,860.
Priya answered them.
She had run those scenarios herself.
She had the batch session logs.
She had the failure mode analysis document she had written when she confirmed the cluster at batch 25,000.
The Network Rail representative asked about the certification process for the amended firmware.
Priya walked through the compliance check process: the 14 failure-mode scenarios, the v2.13 final certification commit, the handover to Network Rail’s safety team.
She answered questions for two hours.
At the end, Holm said: “We’ll be citing the East Midlands firmware as the benchmark for interlocking logic compliance in the interim report. The citation will name you as the signal logic author and the developer of record.”
Priya said: “Yes. Thank you.”
She drove back to Leicester.
She had the Tyne Valley scenario run in progress.
Batch 4,000 would be complete by the time she returned.
She had 36,000 scenarios left.
She had found what she was looking for at batch 23 the last time.
She did not know where she would find it this time.
She would find out when she ran the scenarios.
She drove back.
She checked the scenario run.
Batch 4,100.
She was at the terminal.
She went to work.
—
After the briefing, Holm had asked one more question, off the record.
She had said: “The protocol is named the Kellerman Protocol in the original bulletin. But the firmware originator is UK-7741. Can you tell me how that happened?”
Priya said: “My manager submitted the safety bulletin. He managed the implementation.”
Holm said: “He managed the implementation. Not the design.”
Priya said: “Correct.”
Holm said: “The RAIB report will note that the signal logic was designed by the IRSE-licensed engineer of record. We don’t name the bulletin.”
Priya said: “Understood.”
She drove back to Leicester.
She had batch 4,100 to check.
—
Amir had left a note on her desk when she returned.
It said: “Batch 4,100 complete. Scenarios 3,800-4,100 clear. No failure modes flagged. I’ve set batch 5,000 running.”
She read the note.
She had been gone seven hours.
He had run a batch in her absence.
She had not asked him to.
He had been in the simulation room for all 40,000 scenarios of the East Midlands run.
He knew the protocol.
He had set the next batch running.
She read the note.
She put it with the Tyne Valley project file.
She looked at the terminal.
Batch 5,000 was at 4,712 scenarios.
She sat down.
She opened the output log.
She began reading the results.
She had 35,000 scenarios remaining.
She was at the terminal.
She went to work.
