A network is a graph with capacities
You already know a graph as vertices joined by edges, and in the shortest-path rung you put a number on each edge and called it a weight. A flow network keeps the directed edges but reinterprets that number: instead of a cost to be paid, each edge carries a capacity, a non-negative cap on how much stuff can move along it per unit time. Think of pipes of different widths, or roads of different lane counts, or cables of different bandwidth. Two special vertices are singled out: a source s where everything originates and a sink t where everything must end up. The whole subject is one question — how much can we push from s to t at once?
Picture a tiny example: s points to two middle vertices a and b, and both a and b point to t. The edge s->a can carry 3, s->b can carry 2, a->t can carry 2, and b->t can carry 3. Capacities are fixed properties of the network — they never change. What we get to choose is the flow: an actual amount sent along each edge, which we will pin down precisely in a moment. Keep this four-edge diamond in your head; we will route traffic through it as the rules arrive.
The three rules a flow must obey
A flow assigns to every edge a number f(u,v) — the amount actually flowing on it — and to count as a legal flow it must satisfy two constraints. First, the capacity constraint: on every edge, 0 <= f(u,v) <= c(u,v). You cannot send a negative amount, and you cannot exceed the pipe's width. Second, flow conservation: at every vertex other than s and t, the total flow coming in equals the total flow going out. Nothing is created or stored at an intermediate vertex; whatever arrives must leave. A junction is not a reservoir.
Conservation is the rule that does the real work, so make it concrete on the diamond. Suppose we send 2 along s->a; conservation at a forces 2 to leave a, and the only exit is a->t, whose capacity is exactly 2, so a->t carries 2. Now send 2 along s->b; conservation at b forces 2 out of b via b->t (capacity 3, fine). Check both intermediate vertices: in equals out at a (2 in, 2 out) and at b (2 in, 2 out). Every edge respects its capacity. This is a legal flow. Notice what conservation forbids: we could not have sent 3 into a, because only 2 can leave a, and the extra unit would have nowhere to go.
The value of a flow — the one number we maximize
We now name the prize. The value of a flow, written |f|, is the net amount leaving the source: the total flow on edges out of s, minus any flow on edges back into s. By the balance we just derived, this equals the net amount arriving at t, so you can measure it at either end. In our diamond, with 2 on each of s->a and s->b, the value is 2 + 2 = 4 — four units make the trip from source to sink. The maximum-flow problem is simply: among all legal flows, find one whose value is as large as possible. Everything in this rung — augmenting paths, residual graphs, Ford-Fulkerson — is machinery for pushing that one number up.
Is 4 the best we can do in the diamond? Try to beat it. The two edges leaving s have capacities 3 and 2, so at most 3 + 2 = 5 could ever leave the source. But look at where everything must funnel: edge a->t caps at 2 and edge b->t caps at 3, so at most 2 + 3 = 5 can arrive at t. Both bounds say 5, yet we only reached 4 — could we do better? Push s->a up to 3? No: a->t still only takes 2, so the third unit into a is stuck. The route through a can carry at most min(3,2) = 2, and the route through b at most min(2,3) = 2, so the honest max is 2 + 2 = 4. Both legs are throttled — a's by a->t and b's by s->b. The bottleneck, not the source, decides.
A cut: where you could sever the network
That bottleneck reasoning has a name, and it is the deepest idea in the rung. An s-t cut is any way of splitting all vertices into two teams: a set S that contains the source s, and the rest T that contains the sink t. The capacity of the cut is the total capacity of the edges that cross from the S side to the T side — the cost of completely severing s from t along that particular partition. Different splits give different costs, and each one is a wall standing between source and sink.
Here is the key observation, the one that makes a cut more than a definition: every drop of flow that travels from s to t must, at some point, cross from the S side to the T side, because s is in S and t is in T. So the flow can never exceed the capacity of any cut — the cut is a wall, and no more can pass than the wall's combined width. In symbols, |f| <= capacity(any cut). In the diamond, put a on the s-side together with s, and t and b on the other side. The crossing edges are a->t (capacity 2) and s->b (capacity 2), for a cut capacity of 4 — and our flow of value 4 hits it exactly. We found a cut whose capacity equals our flow's value, which means neither can move: the flow cannot grow past the wall, and no thinner wall exists.
A first taste of the duality to come
We have stumbled onto something remarkable. The value of any flow is at most the capacity of any cut — that direction, called weak duality, we just proved with a one-line argument. The astonishing claim, which the rest of this rung will earn, is that the two actually meet: the maximum flow value equals the minimum cut capacity, always. That is the max-flow min-cut theorem, and it is one of the most celebrated results in all of algorithms. It says the largest amount you can push and the cheapest wall you can build are the same number, even though one is a maximization over flows and the other a minimization over cuts.
One honest caveat before you climb on. Everything here assumes capacities are fixed, non-negative numbers and that flow can take any real value up to the cap. When capacities are whole numbers, the max flow turns out to be achievable with whole-number flows too — a fact that makes flow a perfect lens for problems about indivisible things, like assigning people to jobs. The very next guide builds the residual graph and the augmenting path, the tools that turn this static picture into an actual algorithm; the third guide proves the equality we just previewed; and the fourth shows how plain modeling a problem as a network — most famously matching — lets max-flow do the heavy lifting for you.