The Execution Gap in Safety-Critical Systems
What happens between approval and execution, and why railway infrastructure shows this is not abstract
The previous essay treated approval and execution eligibility as conceptually distinct. The distinction is not new. In safety-critical infrastructure, this distinction has long operated as an engineering constraint rather than a philosophical preference.
This essay reads execution governance through the system that made the distinction unavoidable: the railway.
The argument is straightforward. The execution gap — the interval between when an action is approved and when it actually opens — has been understood as a structural hazard in railway operations for a long time. The mitigation that emerged is called interlocking. The principle behind interlocking is not specific to trains. It is specific to any system in which authority, state, and conditions can drift between the moment of consent and the moment of execution.
The point is not to transplant railway signaling into software. The point is to notice the structural pattern.
That pattern is now relevant far beyond infrastructure. This essay isolates it.
The gap exists because the world does not pause
Between the moment a movement is authorized and the moment a train physically proceeds, time passes. In that time, the world changes.
A track that was clear becomes occupied. A switch that was aligned becomes misaligned. A signal upstream changes state. Another route is cleared into the same conflict point. A worker enters the track for maintenance. An emergency is declared on an adjacent line.
None of these changes invalidate the original dispatch order as a record of intent. The order was valid when it was given. The problem is not the order. The problem is that the order was given against a world that has since moved.
If the railway acted only on the basis of the dispatch order — if the order alone were sufficient to allow movement — the system would not be safe. It would be a system that treats consent as execution permission, and consent does not know what the world is doing right now.
This is the execution gap. It exists in every system where authorization happens before execution and where the world between those two moments is not frozen.
Interlocking is not approval. It is current binding.
The mitigation developed by railway engineers was not better paperwork or stricter approval processes. It was a separate structural layer that lives between authorization and execution.
That layer is interlocking.
Interlocking does not replace the dispatch order. The dispatch order remains the authorization. Interlocking adds something that the dispatch order cannot carry: a check, performed at the moment the signal is about to open, against the current state of the route.
At that moment, the interlocking system asks:
Is the relevant track section clear right now. Are the switches aligned for this specific route right now. Are there conflicting movements authorized into the same path right now. Are the safety conditions for this movement met right now.
If any of these checks fail, the signal does not open. The dispatch order remains valid as a record, but the movement does not occur. The system is not refusing the order. The system is refusing to confuse the order with a guarantee about the present.
This is the operational form of what Concepts 02 called current binding. Interlocking binds the action to the present state, not to the past decision.
Why the principle generalizes
It is tempting to read interlocking as a railway-specific solution. It is not. It is a generalizable answer to a generalizable problem: how to govern execution in any system where authorization and execution are separated by time.
The same structural conditions that made interlocking necessary in railway operations are appearing in other domains.
AI agents receive permissions at the moment of credential issuance, then execute against external systems on those permissions much later. The permission was valid when granted; the state of the world when the action opens is not what the permission assumed.
Automated workflows execute approved tasks across multiple systems. Each system has its own state. The approval was given against an assumed alignment of those states. By the time the workflow opens the action, the alignment may no longer hold.
Continuous deployment pipelines push code into production on the basis of approvals made in the past. The state of production at the moment of deployment is not the state assumed when the approval was given.
In all of these, the same gap exists. The same question applies. Is the action still admissible against the present, or is it relying on a past consent to authorize a present execution.
Railway operations are not the model because trains are special. Railway operations are the model because the consequences of ignoring the gap were unsurvivable. Other domains are now reaching the point where the consequences of ignoring it are becoming visible too.
What this distinguishes from other safety frameworks
Most safety frameworks in software systems operate on a different layer from this problem.
Code review checks the artifact, not its execution. Static analysis examines properties of the code, not properties of the runtime. Penetration testing probes for vulnerabilities, not for execution drift. Compliance audits verify that processes existed, not that the present state was checked when the action opened. Each of these is valuable. But none of them, by itself, performs the same boundary function.
Interlocking is structurally different. It does not improve the approval. It does not analyze the action. It does not test the system afterward. It refuses to let the action open unless the present state, present authority, and present conditions are aligned at the moment of execution.
In many software supply chains, this boundary function is either missing, informal, or distributed across tools that were not designed to perform it explicitly. And increasingly, that absence is the reason for the failures that follow.
Why this matters now
The railway argument is not nostalgia. The reason it matters now is that the systems being built today have the same execution gap as the railways that first formalized this problem, but without the interlocking layer that made railway operations safe.
When an AI agent takes action against external systems based on a permission granted minutes or hours earlier, that is dispatch without interlocking. When a workflow tool fires an automated step against a state that has changed since approval, that is dispatch without interlocking. When a deployment pipeline pushes a change into production without re-evaluating production conditions at the moment of release, that is dispatch without interlocking.
Each of these can be made safer. The pattern is not difficult to describe. The challenge is that most software systems were built with the assumption that approval is enough — that consent given at one moment authorizes execution at another. That assumption is exactly what railway engineering proved insufficient, against a much simpler world than today’s.
The execution gap is not a new problem. It is one of the oldest engineering problems in safety-critical operations. What is new is its appearance in systems whose designers did not know they were operating in a safety-critical domain until something opened that should not have.
Closing
The argument of this essay is narrow. It is not that AI systems should adopt railway signaling. It is that the structural lesson of railway operations — that approval and execution are not the same thing, and that the gap between them requires a separate governance layer — applies wherever execution can drift from the conditions of its approval.
That gap is now visible in domains far beyond infrastructure.
Interlocking, as a principle, is older than computing. The systems that need it most today are the newest ones being built.
Approval set the action in motion. Interlocking decided whether the world was ready for it to open. The two were never the same artifact, and they were never meant to be.