LIRR predeparture TripUpdate freshness semantics

[Tosin Yeku]

We are implementing a transit client using the public LIRR GTFS-RT feed and want to distinguish current operational confirmation from repeated timetable values before a train departs.

In public captures on October 18, 2026, trip `GO202_26_6256_2` (service date `20261018`, scheduled origin departure 15:12 America/New_York) acquired a TripUpdate timestamp of 14:42:45. Our 14:43:05 capture contained that timestamp, but it was still unchanged at 14:49:38 even though the feed header continued advancing. Other captured trains showed similar intermittent updates before their scheduled origin departure. This is an observation, not a claim that the train was late or canceled.

Could you clarify the documented contract for these cases?

1. Before departure, does an unchanged TripUpdate in a newly published full feed affirm that its exact departure and arrival estimates have been revalidated, or can those values remain initialized timetable values without a new operational check?
2. Is there a supported train-specific field or timestamp that distinguishes those states, including when a train is at its origin or has an assigned boarding track?
3. Does a VehiclePosition or railroad status update validate the StopTimeUpdate predictions as well, or only its own position/status fields?
4. If this distinction is unavailable in public GTFS-RT, is there another documented public departure-board or prediction interface intended for it?

We currently preserve the original measurement clock and do not substitute the download time or feed-header time for it. We would like to implement the intended semantics without presenting an old estimate as a newly checked one.