[Realtime] Clarify Trip Update precedence for consumer routing decisions

[tzujenchanmbd]

Context

MobilityData is currently developing Service Alerts guidance to help the community use Service Alerts more consistently. As part of this work, we are gathering feedback through the Service Alerts Working Group meeting.

In the Apr 28 meeting, we discussed how consumers should interpret cases where both Trip Updates and Service Alerts apply but provide conflicting information. The group reached consensus that consumers should by default give precedence to Trip Updates for routing decisions.

Proposed change

This PR adds a clarification to feed-entities.md describing the expected consumer behavior when Trip Updates and Service Alerts both apply.

While this clarification will also be included in the Service Alerts guidance, we believe it is appropriate to include it directly in the specification as well, in order to make this shared expectation clearer.

Because this change clarifies a principle for expected consumer behavior, and does not introduce a new field or functional change, I propose that it can proceed to a vote without requiring implementation testing.

Additional information

Here is the working group meeting notes

We also plan to add an additional Service Alerts meeting in July to continue discussing guidance around Service Alert usage. Registration page

[gcamp]

Sorry I couldn't be there at the workshop! I signed up and completely forgot to add to add my calendar.

The proposal makes sense at first glance, but I'm not sure it works in practice. The problem is that alerts and TripUpdates generally don't work on the time window. TU is generally a couple hours in the future and alerts are multiple weeks in advance.

In a situation where a stop is marked as NO_SERVICE for a week, but the TripUpdates shows regular departure for the next hour, are we expected to show service in the next hour and then all of a sudden shows as closed in an hour? I understand that NO_SERVICE alerts can create false positives, but I don't think this proposal really makes the end situation better. If both are present, I feel the longer timespan one (alert) should have priority.

[tzujenchanmbd]

@gcamp Thanks for raising this, and no worries, we still have a Service Alerts meeting in July! :)

I agree that this PR alone does not solve the broader data quality challenges we have around Service Alerts. I should probably have included more context when opening the PR, since this clarification is only one part of a broader set of work around Service Alerts.

Your example is exactly the type of trade-off we discussed: if a stop has a NO_SERVICE alert for a week, but Trip Updates continue to show departures for the next hour, what should a consumer do?

My understanding from the discussion is that one reason to give Trip Updates default precedence is that they generally provide more specific information about individual trips. That does not mean TripUpdates are always correct, or that a longer-running NO_SERVICE alert should always be ignored. The proposed language tries to preserve that flexibility by including “unless there is clear evidence that the Trip Updates are incorrect.”

I understand your position that the longer-timespan NO_SERVICE alert should have priority in this type of conflict. One challenge I’m trying to think through is how to turn that into a default expectation for consumers. Would alert precedence apply based on the longer time horizon alone, or only when there is additional evidence that the TripUpdate is incorrect?

More broadly, this PR is part of an attempt to find a workable balance around the role of Service Alerts in routing. Some community members have been concerned that Service Alerts should not be used as routing inputs. However, recent discussions, including PR#546, suggest that there is increasing recognition that consumers may use NO_SERVICE alerts as a routing signal, and that this can reduce the burden on producers compared with representing every disruption through TripUpdates.

So I agree this PR does not make the end situation perfect by itself. The goal is more limited: to establish a default expectation for conflict case, while still allowing consumers to use judgment when there is evidence that the Trip Updates are incorrect. The broader Service Alerts work, including PR#546, the Service Alerts Guide, and the cause/effect definitions, is intended to reduce potential conflict cases over time by making producer intent and consumer behavior more consistent.

After further working group discussion, we also plan to add cause/effect definitions to this PR, especially to clarify how NO_SERVICE should be interpreted for different entity.