Requested by John: with both legs of the 26/27 Aug trip claimed (see train-delay-refund-2026-08-26), check for any OTHER delays that might be claimable, using joins between locations (GPS) and the WTT timetable tables on gravlax.
WTT is only loaded for down trains, Paddington → {Bristol Parkway, Swansea, Carmarthen} — so this review covers evening RETURN legs only (Paddington → Bristol Parkway); the outbound commute (up direction) isn't in the DB yet.
Caveat 1: without ticket data in the DB, matching the correct headcode from GPS timing alone is not fully reliable — a 'closest scheduled time' match can pick an on-time later working instead of the true (delayed) booked train, understating the delay. Confidence is noted per finding below.
Caveat 2: the loaded WTT (see wtt-timetable) holds only the BASE schedule per headcode/running-days, valid the whole 18 May–12 Dec period — it does NOT capture short-notice engineering amendments (checked: headcode 1B32 has only one SX schedule for the whole period, no separate engineering-week overlay). Per gwr/engineering-2026, the whole of July (weeks 14–17, 4–31 Jul) was a MAJOR disruption period on this corridor — reduced frequency, diverted (John recalls via Bath), earlier departures — so any July finding below is compared against a timetable that likely wasn't the one actually running that day. Same pattern as the 27 Aug claim, where the live GWR journey planner used a service the base WTT didn't have.
Low confidence on the delay FIGURE, though something was clearly wrong that evening. 23 July falls in Week 16 of the engineering programme (18–24 Jul, MAJOR, all week) — diverted, reduced-frequency running (John recalls via Bath). The comparison below is against the normal base WTT schedule, which almost certainly wasn't the schedule actually in effect that day, so the ~48 min figure is not trustworthy as a delay measurement. The GPS trace itself is solid evidence of disruption (a genuine ~25 min stationary wait at the Paddington platform), just not proof of the compensation-relevant delay against whatever amended timetable applied.
These show a ~15–20 min gap on the nearest-time match, at/near the Delay Repay threshold, but the headcode match is less certain than 23 July's GPS corroboration. Listed for reference, not recommended for a claim without independently confirming the actual train (e.g. a kept ticket):
All other evenings checked (27 Aug, 20 Aug, 19 Aug, 17 Aug, 6 Aug, 3 Aug, 30 Jul, 13 Jul, 9 Jul, 29 Jun) showed on-time or sub-15-min arrivals on the nearest match, or (27 Aug) were already the known, already-claimed delay.
Would need: the ticket photo/reference and price for whichever journey is pursued (WebDAV reclaim/ or wherever it was filed), then the same automated claim flow as delayrepay already handles for the 26/27 Aug claims. These August candidates aren't affected by the engineering-works caveat (disruption calendar shows nothing major after 7 Aug), so the base-WTT comparison is sound — the main open question is confirming the actual train via a kept ticket, since the headcode match is lower-confidence than 23 July's was.