Aggregate segment reliability into a per-operator punctuality metric

[NoamGaash]

⚠️ AI-generated draft — needs human validation

This issue was written by an AI agent from materials produced during the
hasadna Open Bus hackathon (July 2026). The underlying analysis was built fast,
under hackathon conditions, and has not been peer-reviewed. Figures,
endpoint behaviour and conclusions all need independent verification before
anyone acts on them or quotes them publicly.

Please validate before implementing. Corrections very welcome.

The one-sentence version

There is an analysis that shows, for a single bus line, which stop-to-stop segments
take longer than the timetable claims. Roll it up so you can ask the same question
about an entire operator, or an entire region.

Background — what already exists

You don't need to have seen the hackathon to follow this.

The measurement. For one bus line, take each stop-to-stop segment (stop 3 → stop
4, say) and compare how long buses actually take against how long the published
GTFS timetable says they should. The output is a ratio per segment: 1.0 means the
timetable is right, 1.6 means the segment reliably takes 60% longer than scheduled.
The hackathon write-up reports ratios reaching ~2.5× on bottleneck segments during
rush hour, and concludes that schedulers write near-free-flow durations with no
traffic margin — (their finding, not independently verified here).

That analysis is already ticketed for דאטאבוס in three views:

• Segment reliability: where the timetable is optimistic #1782 — the per-segment bar chart ("where the timetable is optimistic")
• Marey time-space diagram for one line #1783 — the Marey time-space diagram ("where the bus loses time")
• Segment × hour heatmap: which segments break down at rush hour #1784 — the segment × hour heatmap ("which segments break down at rush hour")

All three are single-line views. You pick a line, you look at that line.

What this ticket asks for

Turn that into a number that can be compared: per line → per operator → per region.
A single "how realistic are this operator's timetables" figure.

Concretely:

• Aggregate segment ratios up to a per-line score, then per-operator, then per-region
• Weight segments by ride volume — a segment served twice a day must not
  dominate a segment served 200 times a day
• Publish sample size and confidence alongside the headline. The underlying
  analysis already computes a per-segment confidence verdict (implausible value
  → few samples → patchy coverage → coarse GPS timing → loose stop match
  → ok). That must survive the rollup, not get averaged away.
• Exclude operators outside the SIRI feed rather than scoring them badly.
  This is not hypothetical — see the warning below.

⚠️ The exclusion problem is real, please don't skip it

An operator with no real-time feed has no actual travel times, which naively reads as
"no data" and can easily become "bad score". Verified live on 2026-08-16 against
/rides_execution/list and /siri_rides/list for 2026-08-01 → 08-15:

• כרמלית (operator_ref 20) returns zero rows from /siri_rides/list. It's the
  Haifa funicular — it has no SIRI feed at all.
• כפיר (operator_ref 21) has only ~3% of its planned rides matched to actuals, but
  it does appear in the SIRI feed — so a simple "is this operator absent?" check
  will not catch it.

Any operator-level metric in this milestone hits the same wall. See #1801 for the
same problem worked through in detail on a different metric, and #1780 for the
underlying data issue.

Why it's worth your time

Every reliability view in this milestone is single-line. A single-line view answers
"is my commute bad". It cannot answer "is this operator worse than that one", which
is the question a regulator, a journalist, or a rider choosing between two competing
operators actually asks. This is the step that turns a demo into a metric.

It is also the honest counterpart to the "days without cancellations" work (#1801):
that metric measures whether the bus ran, this one measures whether the timetable
was ever achievable. An operator can be blamed for the first; the second is often
the scheduler's fault, not the driver's — and separating those two is genuinely
useful.

Blocked on

#1803. The whole thing rests on derived stop arrival times, which the API does not
serve — they're interpolated from raw GPS, at a cost the hackathon write-up puts at
~1–2 minutes per line. Doing that for every line of every operator is not viable
until it's pre-aggregated. You can prototype on a handful of lines today; you cannot
ship a national number.

Getting started

• Skills: Python or TypeScript; comfort with weighted aggregation and with
  reporting uncertainty rather than hiding it.
• Reference implementation:
  analyses/bus_arrival_reliability.py,
  written up in
  algorithms/bus-arrival-reliability.md.
• Read the "Criticism" section of that write-up before designing anything. The
  short version: GPS pings arrive ~once a minute, so derived arrivals are ±30 s. For
  urban stops less than 60 s apart, a single ride's segment duration is mostly noise.
  Any rollup has to lean on multi-ride aggregation and be explicit about it.
• No API key needed — the checked-in .env points at production.

Related tickets

#1782, #1783, #1784 (the single-line views this rolls up) · #1803 (blocker) ·
#1801 (same operator-exclusion problem, worked through) · #1800 (sibling rollup, for
headway regularity)

---

Credit & provenance
Found during the hasadna Open Bus hackathon, July 2026 — analysis by the hackathon team.
· Method, evidence and caveats: algorithms/upstream-issues.md
· Original work: https://github.com/hasadna/open-bus-hackathon-26
· Issue drafts and the full defect list: algorithms/upstream-issues.md

Rewritten 2026-08-16 to be readable without the hackathon materials. The operator
feed-coverage figures were measured live on that date; the segment-ratio findings are
the hackathon team's and were not re-verified.