transit has two graphs. Not because one is better — because there are two questions.

The first: the stop graph

A node is a stop. There is an edge A→B if some trip runs from A to B with no stop in between.

stop graph        1,531 nodes, 2,190 edges
BFS per query     5.8 – 8.3 µs

The mean degree is 2190 / 1531 = 1.43. Your library network's is 1.49. Nearly the same number, and not by accident: both networks are long chains with rare junctions.

transit's own source notes say the median is 1. That is their claim, not our measurement — treat it exactly as lesson 2 treated the slice-header arithmetic.

And the consequence of that smallness is stated in the same place: it is why BFS here costs microseconds, and why this graph could never carry the priority-queue comparison. Lesson 15 will demand that comparison, and it will need a different graph.

Why there is NO time in this graph

This is the important idea in the step, and it is not about speed.

transit's source says it outright:

Time is deliberately absent: the question is a hop count, so the model is a hop graph and BFS is exactly right.

"What is the fewest stops from A to B?" is counting hops. How many minutes each leg takes does not enter the answer. If time were in the model it would be data the question never asks about — and BFS would ignore it anyway.

The model matches the question. Not the other way round.

The second: the time-expanded graph

Now ask a different question: "when is the earliest I can arrive?"

The hop graph cannot answer that — not slowly, but in principle. There is no time in it. The distance between two stops there is "one edge", and that is all.

So transit has a second graph, where a node is not a stop but an event: a particular bus at a particular stop at a particular time.

time-expanded graph   206,875 nodes, 422,661 edges

The same city. 135× more nodes, because instead of 1,531 stops there is every departure of the day, separately.

And the representation changed with it

In step 7 you measured that the gap between a matrix and a list grows with V. transit shows the same thing along another axis — its two graphs are stored differently:

	nodes	how it is stored
stop graph	1,531	adj [][]int32 — a slice of slices
time-expanded	206,875	offsets []int32 + edges []Edge — one flat array

The second is exactly what lesson 2 calculated: at 206,875 nodes, separate headers would cost ~5 MB in pointers alone, so transit does not have them.

The same program, two graphs, two representations, and the size decides.

Why BFS does not belong there

Run BFS on the time-expanded graph and it will work. And it will answer "in the fewest events".

Nobody asked that.

Fewest events is not the earliest arrival, nor the fewest transfers, nor the shortest time. It is a correct answer to a question that does not exist.

BFS answers "in how many hops", because every hop costs the same. In the time-expanded graph they do not — and BFS ignores that.

That is where this lesson ends and the next begins. Once edges stop being equal you need a search that counts cost rather than hops — and a queue that hands back the cheapest one every time.

You built that queue in lesson 13.