The objection that should win
Here is the strongest case against this whole page: rail networks already have a name for what happens to old data, and it is called the incident report. Every track circuit failure, every axle-counter fault, every temporary speed restriction is logged, timestamped, closed out and archived under a retention schedule set by the infrastructure manager and, in most jurisdictions, by statute. Network Rail keeps safety-critical records for decades. Nothing is quietly forgotten. If garbage collection is about deciding what to discard, rail operations solved that problem long before anyone called it garbage collection, and solved it more rigorously than any tracing collector — with human sign-off, not a mark bit.
That objection is correct about archives and wrong about belief. The incident report answers "what happened and when." It does not answer the question a network controller must answer every ninety seconds: is the belief I am currently acting on — this line is clear, that gauge corner is sound, this axle-counter reading is trustworthy — still supported by anything live, or is it propped up only by a reading that arrived four shift changes ago and was never revisited because nothing forced the revisit. Archiving the past and reclaiming the present are different disciplines. Rail operations has built the first one exhaustively. The second one is where this page's argument actually bites.
What the network streams
A control centre ingests track circuit state (occupied, clear, or the ambiguous third state that is neither), rolling-stock telemetry from any train fitted to report it — bogie temperature, wheel-flat detection, brake pressure — weather feeds relevant to adhesion and to structures at risk of scour or landslip, and maintenance windows: possessions granted, engineering trains running, temporary blockages. None of these streams stop. A track circuit does not have a scene boundary the way a single journey does; it reports for as long as the section exists. Telemetry from a fleet in service reports for as long as the fleet is in service. This is the domain condition the lineage names: not a corpus fixed at a point, not a bounded episode with a clean exit, but everything, continuously, with no stopping point built into the intake itself.
The consequence is that "clear line" is not a fact retrieved once. It is a belief with an evidence trail, and that trail has a half-life. A track circuit that reported clear at 14:02 is not still clear by virtue of having reported so at 14:02; it is clear because nothing since 14:02 contradicts it and the circuit itself has not failed silently, which track circuits are known to do. The belief needs to be re-derived from live evidence continuously, or explicitly marked as resting on ageing evidence, or retired. That is a collection problem stated in operational language.
The failure mode is a timing bug, not a data-loss bug
The characteristic failure in this domain is not that a defect goes unrecorded. It is recorded — usually several times, by several systems, in slightly disagreeing terms. The failure is that the speed restriction gets applied after the defect has already propagated: after a rough ride report, a wheel-impact spike and a rail-temperature alert have separately arrived, been separately logged, and sat as three unlinked entries rather than one escalating belief, until a fourth signal — a broken rail detection, or a derailment — forces the correlation that should have happened on the first or second signal.
This is a reachability failure, precisely in the collector's sense. Each report is live evidence. Each is reachable from a root — a sensor, a train, a maintenance log. But nothing in the system was tracing continuously to check whether those three reachable facts pointed at the same underlying object: this half-mile of track, this specific rail joint. The pointers existed. Nobody walked the graph until the tracing was already too late to matter. A network controller ends up applying the restriction at the moment the defect becomes undeniable, which is downstream of the moment it became evident. The gap between those two moments is exactly the collector's pause, except here nobody engineered the pause; it simply exists, unbudgeted, in whatever workflow correlates alerts by hand.
Storage is not the issue here. We keep everything — every circuit event, every telemetry frame, every weather cell. The problem is retrieval discipline, not garbage collection. You're dressing up a data-integration failure in computer-science vocabulary it doesn't need.
That objection deserves a straight answer, because it is half right.
Where the cheap-storage objection lands, and where it doesn't
Storage in rail operations is not the constraint. Telemetry retention has got dramatically cheaper over the last decade, and infrastructure managers keep long histories of circuit state without much anxiety about the bytes. So if garbage collection meant "delete old readings to save disk," the objection wins outright: nobody needs to delete a track circuit log.
But reachability is not about bytes, it is about which of ten mutually adjacent readings a controller's current belief should actually rest on. A joint with a known slow-growing defect will, over a maintenance cycle, generate a rough-ride report, two telemetry spikes from different trains, a scheduled ultrasonic test result, and a weather-linked adhesion warning for the same stretch. Keeping all five costs nothing. Determining that all five are evidence about the same live belief — this joint, this defect, escalating — rather than five independent, low-priority anomalies, is exactly the tracing work a collector does: starting from roots (the physical asset, the section identifier), walking outward through everything currently pointing at it, and deciding what is still reachable as one connected, escalating case rather than five disconnected footnotes. The database vacuums fine. The belief graph does not maintain itself.
The second objection worth taking seriously is the maintenance-is-universal one: signalling systems already run interlocking checks, telemetry pipelines already run deduplication, this is just ordinary system upkeep dressed in unfamiliar language. That is fair as far as it goes — all long-running systems need upkeep, rail control is no exception, and nothing here claims otherwise. The narrower and more useful claim is about scheduling. A timetabled maintenance possession can be planned outside traffic, the way a database vacuum can be scheduled outside peak load. A live network cannot be taken offline to reconcile beliefs about where its defects are; the reconciliation has to run concurrently with the traffic it is protecting, at whatever rate new telemetry arrives, without ever pausing the network to do it. That is a genuinely different engineering demand from a nightly batch job, and it is the demand rail control shares with any system whose intake never closes.
What this rules out and what it doesn't
None of this argues for automating the network controller out of the loop, or for a rule engine that silently expires alerts on a fixed clock. Static expiry — "discard any anomaly report older than 72 hours with no corroboration" — handles the easy cases and will misfire on the hard ones: the defect that develops slowly across six weeks of marginal readings, none individually alarming, all pointing the same direction. Reachability from live evidence has to be re-evaluated as evidence arrives, not decided in advance by a stamp. That is the same limit static lifetime analysis hits in any domain with an open stream: the compiler, or the schedule, can only reason about what it can see in advance, and a live network's future evidence is not yet in.
The claim that survives
Rail control does not need reminding to keep its records; it already keeps them, exhaustively and under legal duty. What it needs, and what the intake axis actually predicts, is a standing discipline for deciding, continuously and while trains are moving, which of the day's scattered readings are still separate facts and which have quietly become one escalating belief about one piece of track — before the fourth alert makes the answer obvious to everyone, including the passengers on the train that hits the joint first. That discipline has no natural resting point, no scene boundary, no build step. It runs for as long as the track does. That is the terminal condition this whole lineage is describing, and rail operations is simply where it shows up as a speed restriction filed a shift too late.