Understand the failure.
Verify the repair.
Small, reproducible software failures. The broken implementation, the fix that didn’t work, and the one that passed—preserved together.
Explore the cases ↓How results are verified ↗WHAT THE ARCHIVE CONTAINS
100840 executable cases. 20168 are open.
Every case records the implementation that fails, the fix that did not work, and the repair that passed its checks—with recorded outputs and source hashes. This release adds 100840 cases across 20168 failure mechanisms and 254 domains.
The open tier gives you the failure and the unsuccessful fix for one case in every mechanism. The remaining 80672 cases, 5 variants per mechanism, are member-only: the verified repair, its recorded checks, and the full fixture suite are held in the member archive. Read the methodology ↗
A RECORD OF WHAT WENT WRONG
Browse the archive / 100840
Call-on permissive move authorisation: standing time boundary · case 01
A train that has stood exactly two minutes is refused the call-on.
Call-on permissive move authorisation: standing time boundary · case 02
A train that has stood exactly two minutes is refused the call-on.
Call-on permissive move authorisation: standing time boundary · case 03
A train that has stood exactly two minutes is refused the call-on.
Call-on permissive move authorisation: standing time boundary · case 04
A train that has stood exactly two minutes is refused the call-on.
Call-on permissive move authorisation: standing time boundary · case 05
A train that has stood exactly two minutes is refused the call-on.
Call-on permissive move authorisation: stationary requirement · case 01
A call-on is given to a train still rolling towards the signal.
Call-on permissive move authorisation: stationary requirement · case 02
A call-on is given to a train still rolling towards the signal.
Call-on permissive move authorisation: stationary requirement · case 03
A call-on is given to a train still rolling towards the signal.
Call-on permissive move authorisation: stationary requirement · case 04
A call-on is given to a train still rolling towards the signal.
Call-on permissive move authorisation: stationary requirement · case 05
A call-on is given to a train still rolling towards the signal.
Call-on permissive move authorisation: moving occupant check · case 01
A call-on is given towards a train that is moving in the platform.
Call-on permissive move authorisation: moving occupant check · case 02
A call-on is given towards a train that is moving in the platform.
Call-on permissive move authorisation: moving occupant check · case 03
A call-on is given towards a train that is moving in the platform.
Call-on permissive move authorisation: moving occupant check · case 04
A call-on is given towards a train that is moving in the platform.
Call-on permissive move authorisation: moving occupant check · case 05
A call-on is given towards a train that is moving in the platform.
Call-on permissive move authorisation: main aspect precedence · case 01
A train approaching a clear platform is refused a main aspect because it has not stood at the signal.
Call-on permissive move authorisation: main aspect precedence · case 02
A train approaching a clear platform is refused a main aspect because it has not stood at the signal.
Call-on permissive move authorisation: main aspect precedence · case 03
A train approaching a clear platform is refused a main aspect because it has not stood at the signal.
Call-on permissive move authorisation: main aspect precedence · case 04
A train approaching a clear platform is refused a main aspect because it has not stood at the signal.
Call-on permissive move authorisation: main aspect precedence · case 05
A train approaching a clear platform is refused a main aspect because it has not stood at the signal.
Vital telegram acceptance: sequence wraparound · case 01
The link drops to safe state every time the sequence number wraps.
Vital telegram acceptance: sequence wraparound · case 02
The link drops to safe state every time the sequence number wraps.
Vital telegram acceptance: sequence wraparound · case 03
The link drops to safe state every time the sequence number wraps.
Vital telegram acceptance: sequence wraparound · case 04
The link drops to safe state every time the sequence number wraps.
Vital telegram acceptance: sequence wraparound · case 05
The link drops to safe state every time the sequence number wraps.
Vital telegram acceptance: sequence window · case 01
A duplicated telegram is accepted as fresh.
Vital telegram acceptance: sequence window · case 02
A duplicated telegram is accepted as fresh.
Vital telegram acceptance: sequence window · case 03
A duplicated telegram is accepted as fresh.
Vital telegram acceptance: sequence window · case 04
A duplicated telegram is accepted as fresh.
Vital telegram acceptance: sequence window · case 05
A duplicated telegram is accepted as fresh.
Vital telegram acceptance: telegram age · case 01
Delayed or impossible telegrams are acted upon.
Vital telegram acceptance: telegram age · case 02
Delayed or impossible telegrams are acted upon.
Vital telegram acceptance: telegram age · case 03
Delayed or impossible telegrams are acted upon.
Vital telegram acceptance: telegram age · case 04
Delayed or impossible telegrams are acted upon.
Vital telegram acceptance: telegram age · case 05
Delayed or impossible telegrams are acted upon.
Vital telegram acceptance: recovery run reset · case 01
The link leaves safe state on two good telegrams separated by a bad one.
Vital telegram acceptance: recovery run reset · case 02
The link leaves safe state on two good telegrams separated by a bad one.
Vital telegram acceptance: recovery run reset · case 03
The link leaves safe state on two good telegrams separated by a bad one.
Vital telegram acceptance: recovery run reset · case 04
The link leaves safe state on two good telegrams separated by a bad one.
Vital telegram acceptance: recovery run reset · case 05
The link leaves safe state on two good telegrams separated by a bad one.
Vital telegram acceptance: link timeout reference · case 01
The link times out on an exact timeout gap, or never times out while only garbage arrives.
Vital telegram acceptance: link timeout reference · case 02
The link times out on an exact timeout gap, or never times out while only garbage arrives.
Vital telegram acceptance: link timeout reference · case 03
The link times out on an exact timeout gap, or never times out while only garbage arrives.
Vital telegram acceptance: link timeout reference · case 04
The link times out on an exact timeout gap, or never times out while only garbage arrives.
Vital telegram acceptance: link timeout reference · case 05
The link times out on an exact timeout gap, or never times out while only garbage arrives.
Sequential point throwing under a power budget: lock check scope · case 01
A route sharing a point in the same lie with another route is refused.
Sequential point throwing under a power budget: lock check scope · case 02
A route sharing a point in the same lie with another route is refused.
Sequential point throwing under a power budget: lock check scope · case 03
A route sharing a point in the same lie with another route is refused.
Sequential point throwing under a power budget: lock check scope · case 04
A route sharing a point in the same lie with another route is refused.
Sequential point throwing under a power budget: lock check scope · case 05
A route sharing a point in the same lie with another route is refused.
Sequential point throwing under a power budget: throw time lookup · case 01
Route setting time ignores the individual throw time of slow or fast points.
Sequential point throwing under a power budget: throw time lookup · case 02
Route setting time ignores the individual throw time of slow or fast points.
Sequential point throwing under a power budget: throw time lookup · case 03
Route setting time ignores the individual throw time of slow or fast points.
Sequential point throwing under a power budget: throw time lookup · case 04
Route setting time ignores the individual throw time of slow or fast points.
Sequential point throwing under a power budget: throw time lookup · case 05
Route setting time ignores the individual throw time of slow or fast points.
Sequential point throwing under a power budget: completion time · case 01
The route is reported ready at the wrong time.
Sequential point throwing under a power budget: completion time · case 02
The route is reported ready at the wrong time.
Sequential point throwing under a power budget: completion time · case 03
The route is reported ready at the wrong time.
Sequential point throwing under a power budget: completion time · case 04
The route is reported ready at the wrong time.
Sequential point throwing under a power budget: completion time · case 05
The route is reported ready at the wrong time.
Sequential point throwing under a power budget: undetected point handling · case 01
A point without detection is assumed to lie correctly and is not thrown.
Sequential point throwing under a power budget: undetected point handling · case 02
A point without detection is assumed to lie correctly and is not thrown.
Sequential point throwing under a power budget: undetected point handling · case 03
A point without detection is assumed to lie correctly and is not thrown.
Sequential point throwing under a power budget: undetected point handling · case 04
A point without detection is assumed to lie correctly and is not thrown.
Sequential point throwing under a power budget: undetected point handling · case 05
A point without detection is assumed to lie correctly and is not thrown.
Sequential point throwing under a power budget: supply slot choice · case 01
Points wait for a busy supply while another supply is idle sooner.
Sequential point throwing under a power budget: supply slot choice · case 02
Points wait for a busy supply while another supply is idle sooner.
Sequential point throwing under a power budget: supply slot choice · case 03
Points wait for a busy supply while another supply is idle sooner.
Sequential point throwing under a power budget: supply slot choice · case 04
Points wait for a busy supply while another supply is idle sooner.
Sequential point throwing under a power budget: supply slot choice · case 05
Points wait for a busy supply while another supply is idle sooner.
Flank protection selection: lock agreement · case 01
A flank point already locked in the protecting lie is treated as unavailable.
Flank protection selection: lock agreement · case 02
A flank point already locked in the protecting lie is treated as unavailable.
Flank protection selection: lock agreement · case 03
A flank point already locked in the protecting lie is treated as unavailable.
Flank protection selection: lock agreement · case 04
A flank point already locked in the protecting lie is treated as unavailable.
Flank protection selection: lock agreement · case 05
A flank point already locked in the protecting lie is treated as unavailable.
Flank protection selection: own flank demand · case 01
Two route points silently overwrite each other's flank demand on a shared flank point.
Flank protection selection: own flank demand · case 02
Two route points silently overwrite each other's flank demand on a shared flank point.
Flank protection selection: own flank demand · case 03
Two route points silently overwrite each other's flank demand on a shared flank point.
Flank protection selection: own flank demand · case 04
Two route points silently overwrite each other's flank demand on a shared flank point.
Flank protection selection: own flank demand · case 05
Two route points silently overwrite each other's flank demand on a shared flank point.
Flank protection selection: indirect protection availability · case 01
A route is protected by a flank signal that cannot actually be held.
Flank protection selection: indirect protection availability · case 02
A route is protected by a flank signal that cannot actually be held.
Flank protection selection: indirect protection availability · case 03
A route is protected by a flank signal that cannot actually be held.
Flank protection selection: indirect protection availability · case 04
A route is protected by a flank signal that cannot actually be held.
Flank protection selection: indirect protection availability · case 05
A route is protected by a flank signal that cannot actually be held.
Flank protection selection: flank table key · case 01
Route points receive no flank protection or the wrong one.
Flank protection selection: flank table key · case 02
Route points receive no flank protection or the wrong one.
Flank protection selection: flank table key · case 03
Route points receive no flank protection or the wrong one.
Flank protection selection: flank table key · case 04
Route points receive no flank protection or the wrong one.
Flank protection selection: flank table key · case 05
Route points receive no flank protection or the wrong one.
Flank protection selection: held signal list · case 01
The held signal list repeats a signal or is out of order.
Flank protection selection: held signal list · case 02
The held signal list repeats a signal or is out of order.
Flank protection selection: held signal list · case 03
The held signal list repeats a signal or is out of order.
Flank protection selection: held signal list · case 04
The held signal list repeats a signal or is out of order.
Flank protection selection: held signal list · case 05
The held signal list repeats a signal or is out of order.
Automatic route setting arbitration: lookahead window · case 01
An overdue train or one arriving exactly at the horizon gets no route.
Automatic route setting arbitration: lookahead window · case 02
An overdue train or one arriving exactly at the horizon gets no route.
Automatic route setting arbitration: lookahead window · case 03
An overdue train or one arriving exactly at the horizon gets no route.
Automatic route setting arbitration: lookahead window · case 04
An overdue train or one arriving exactly at the horizon gets no route.
Automatic route setting arbitration: lookahead window · case 05
An overdue train or one arriving exactly at the horizon gets no route.
INSPECTABLE BY DESIGN
Every result has a runnable source.
Runnable implementations with recorded outputs, source hashes, and explicit contracts. Related variants share a failure mechanism and belong together in evaluation splits.
Read the methodology ↗