Thanks @jamesevans
Looking at /Line/Route as extracted on 23/6, i.e. with timestamps of 21/6, I can indeed see that the 307 has validTo dates of 23/6 for both directions.
Three thoughts arise from this:
Firstly, looking manually at /Line/Route extracted now (26/6), the 307 has disappeared, as expected, but I am not seeing any amended timestamps for other routes. To take route 26 as an example, which has a scheduled timetable change on the Saturday, the created and modified timestamps are still showing as 21/6 but the validity period has changed from 17/6-23/6 to 24/6-23/12. Surely this is a modification?
Secondly, if the data is due to expire within the week following the bulk update, should there be further routeSections for the latter half of the period (leaving aside the error that prevented the new 307 being loaded)?
Thirdly, I use lineId/originator/direction from this to generate /Line/Timetable calls, but neither those calls nor responses have any validity information. Is the timetable only good for the day that the request is made, good until the validTo date, or an agglomeration of all current and forward timetables?
I note that, in /Line/Route/Sequence, we get fairly frequent instances of duplicate stopPointSequences, normally reflecting changes to the route during the week. It would seem that the presentation of data is not consistent between the two calls
As a further issue, the bulk update last week was timestamped 21/6, actually published on 23/6 with a number of lines, including 307 and 26, due to expire on the same day, which makes the data pretty useless for forward planning.