FA-66907 / Railway interlocking logic / Member archive

Point machine throw control: in-position under lock · case 02

A command matching the current lie is refused because the point is locked.

Member previewVariant 2 · 3 implementations · 8 checks per implementation

Case contract

A point command is answered as in-position when already detected in the commanded lie (even if locked or occupied). Otherwise route locking refuses (route-locked), then track locking refuses (track-locked); the alarm flag on refusals is raised only when the point has lost detection (X). A throw that fails to regain detection within limit_ms (inclusive; None means never) leaves the point X with alarm; otherwise it lies in the commanded position. detected_ms of 0 means detection was immediate.

Why this case matters

Interlocking logic decides whether trains may be given authority; a wrong decision at this point either grants unsafe movements or strands traffic.

One recorded failure

Sample boundary fixture

This sample comes from the broken implementation of a controlled reproducer.

Boundary fixture	Actual	Expected	Outcome
regression: already normal under a train	`{"alarm": false, "pos": "N", "result": "track-locked"}`	`{"alarm": false, "pos": "N", "result": "in-position"}`	Failed

MEMBER ARCHIVE

The complete case is available to members.

This record includes three runnable implementations, regression fixtures, execution results, and source hashes.

Member access is invitation-based. Sign in with your invited account to inspect the sources.