FA-67262 / Railway interlocking logic / Member archive

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.

Member previewVariant 2 · 3 implementations · 8 checks per implementation

Case contract

A route needs points in given lies (processed in list order). Points already detected in the needed lie are skipped; an undetected point (missing from current) must be thrown. A point that must move but is locked by another route blocks the whole request (blocked:<p>, nothing thrown). At most max_parallel points move at once: each point starts on the earliest-free supply slot (lowest index on ties) and takes its own throw time or the default. Return the start time per thrown point and the time all have finished.

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: undetected point	`{"done_s": 5, "result": "set", "starts": {"P2": 0}}`	`{"done_s": 5, "result": "set", "starts": {"P1": 0, "P2": 0}}`	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.