The Gold Standard of Urban Systems | Testing Neighbourhood Service Demands Against Shared Route Capacity

Willow Yard supplies identical fictional crates to neighbourhood service points A and B. Each point requests seventy crates during one stated reporting window. The yard has 150 crates available. The question is whether both seventy-crate requests can be met within the window under the supplied allocation constraints.

We initially treat movement as a static capacity account. Each link has a maximum transferable amount for that same window. Travel times, queues, loading schedules and reliability are excluded, with those limitations kept visible. A mathematically feasible allocation is therefore not automatically a complete operating schedule.

The Urban Systems subject guide follows connections between places, services and ordinary life. Here we develop one narrow service question: can several claims using the same network hold together, rather than merely work in separate demonstrations?

Begin with the destination requirements, not with the number of route lines on a drawing. Total requested delivery is 140 crates, but that total alone is not the full condition. A must receive seventy and B must receive seventy. Sending 140 to the wrong place, or counting one movement towards both destinations, would not meet the stated task.

Contents · Next chapter

The yard S connects to a shared hub H through a link carrying at most one hundred crates in the window. H connects to A with capacity eighty and to B with capacity eighty. A separate direct link from S to B carries at most twenty.

Each service point can receive at most eighty crates in the window. The source inventory is 150. All capacities refer to identical crate units and the same window. Links are directed as listed; an unlisted reverse movement is not assumed.

Distinguish a link limit from a destination limit. The H-to-B and direct-to-B links are separate routes, but their combined arrivals still face B’s receiving condition. Equally, the two hub routes share the one S-to-H resource.

This is a model of physical contributions, rather than a count of names. If two drawn links actually refer to the same operating resource, the model needs that shared relationship. Otherwise the diagram can create apparent capacity that the underlying system never supplied.

Contents · Previous chapter · Next chapter

Let x be crates sent S–H–A, y be crates sent S–H–B and z be crates sent directly S–B. A receives x. B receives y + z. The shared S-to-H use is x + y.

The main constraints are x + y ≤ 100, x ≤ 80, y ≤ 80, z ≤ 20 and y + z ≤ 80. Total dispatch x + y + z cannot exceed 150. All quantities are nonnegative. These inequalities keep resource use and delivered service connected.

For the original requests, we additionally require x = 70 and y + z = 70. A proposed solution must satisfy the complete set together. Checking each route in isolation leaves out the shared x + y condition.

The algebra is a compact version of an ordinary contribution table. Each crate on the hub route consumes one unit of the shared link; it does not become available there again because its destination has another label. No specialised algorithm is needed to discover the first contradiction. A learner should be able to translate between the inequalities and the physical resource being counted, then identify which constraint rejects a proposed allocation.

Contents · Previous chapter · Next chapter

If only A requests seventy crates, choose x = 70, y = 0 and z = 0. The shared link uses seventy, A’s route and receiving limits are respected, and sufficient source inventory exists.

If only B requests seventy, choose x = 0, y = 50 and z = 20. The shared link uses fifty, the direct link twenty and B receives seventy. That separate test also works.

Combining those independently chosen plans would give x = 70, y = 50 and z = 20. A and B would each receive seventy on paper, but the shared link would need x + y = 120, above its limit of one hundred.

The individual feasibility findings were correct for the questions they answered. The invalid step was treating their resource availability as independent when combining them. This is a useful way to explain a failed combined service claim without dismissing every earlier test.

For a review, keep the simultaneous condition explicit. Were other demands absent during each demonstration? Which resources would those demands share during actual use? A success record for one destination under an otherwise unused network cannot establish the full allocation for several destinations competing within one window.

Contents · Previous chapter · Next chapter

Every crate leaving S for these destinations must use either the S-to-H link or the direct S-to-B link. Their combined capacity is 100 + 20 = 120 crates in the window. No allocation can deliver more through this boundary under the stated model.

This is a cut argument: separate the source from the destinations and account for the capacity crossing that separation. It gives an upper bound on total transfer. In this simple network, the boundary consists of two plainly identified outgoing links.

The original requests total 140, exceeding that bound by twenty. Both requests cannot be met together, regardless of how the hub’s outgoing links are divided. Trying more arbitrary splits will not overcome the shared boundary.

Google’s maximum-flow documentation describes networks whose directed arcs constrain the amount carried in a fixed period. Our network and service comparisons are independently constructed. The useful first-principles idea is that every valid route must cross the identified boundary, so every transferred unit consumes some part of its capacity. A beautiful diagram with many downstream alternatives cannot make that crossing requirement disappear.

A total boundary check is necessary, but it does not by itself establish every destination requirement. Suppose a new request asks for ninety at A and thirty at B. Its total is 120, equal to the source-boundary limit, but A’s own route and receiving limits are eighty. The request is still infeasible.

We can describe the full request region for this small baseline network. Let a and b be the requested amounts at A and B. They must be nonnegative and each no greater than eighty. A must use a units of the shared link. B needs at least max(0, b − 20) shared units because its direct route can supply at most twenty. A further necessary condition is therefore a + max(0, b − 20) ≤ 100.

Under the complete original assumptions, these conditions are also sufficient. Set x = a, z = min(b, 20) and y = b − z. The shared use is exactly the left side of that inequality, B receives b and the remaining listed limits hold. Source use cannot exceed 120 in this construction, so the 150-crate inventory is sufficient.

For example, eighty at A and forty at B works with x = 80, y = 20 and z = 20. Ninety at A and thirty at B fails its destination condition even though the totals match. The two requests therefore share one aggregate number but differ in feasibility.

This is a useful extension beyond searching for a single maximum total. A service promise is a vector of destination quantities. A complete answer keeps those identities instead of allowing a favourable total to conceal a shortfall at one required place. The sufficiency argument applies to this simple supplied network; additional compatibility or operating constraints can require more conditions.

Contents · Previous chapter · Next chapter

Choose x = 60, y = 40 and z = 20. The shared link carries one hundred, the direct link twenty, A receives sixty and B receives sixty. Destination limits, hub links and source inventory all satisfy the ledger.

Total delivery is 120 crates. Since the preceding cut argument showed that no delivery can exceed 120, this feasible construction establishes the maximum total for the stated model. The upper bound and matching allocation support the conclusion together.

This proves a maximum aggregate result. It does not prove that the original seventy-crate service requirements were met. Each destination is ten short. Preserve both facts rather than using the word optimal to imply success against a different objective. An optimum is meaningful only with the quantity being optimised and the constraints under which it was obtained.

Contents · Previous chapter · Next chapter

Another maximum-total plan sends seventy to A and fifty to B: x = 70, y = 30, z = 20. A’s whole request is met, while B receives approximately 71.4% of its seventy-crate request. Reversing the outcome is also possible with x = 50, y = 50 and z = 20.

The sixty-and-sixty allocation instead provides each destination with 60/70 = 6/7, approximately 85.7% of its request. It maximises the common fulfilment fraction in this symmetric-demand model.

To see the bound, let both receive at least 70α. Their combined delivery must be at least 140α and cannot exceed 120, so α ≤ 6/7. The sixty-and-sixty construction reaches that bound. That proves the stated common-fraction result, rather than declaring equality desirable by intuition alone.

The model does not determine the real priority rule. Actual service responsibilities, different needs and consequences may justify another arrangement. Mathematics can reveal the feasible trade-off and the effect of a selected rule. It cannot quietly turn maximum total, equal amounts or equal fractions into the same ethical or institutional decision. Report the allocation and criterion so the people responsible can assess the choice.

Contents · Previous chapter · Next chapter

Suppose a draft plan assigns sixty crates to each hub route, x = 60 and y = 60, with no direct use. Each outgoing route stays below eighty, but their shared use totals 120. The plan is infeasible.

Moving twenty of B’s crates onto the direct route changes the plan to x = 60, y = 40 and z = 20. B still receives sixty. The shared use falls to one hundred, producing the feasible maximum-total allocation already checked.

This example shows why an alternative route can be useful even when it does not change the destination’s requested amount. It releases a shared resource for other users. Its value depends on which constraint was controlling the combined plan.

In an actual service, rerouting also needs appropriate permissions, compatibility, timing and operating evidence. Our model supplies those conditions abstractly for identical crates. The calculation is a way to ask a clearer question: which movement can legitimately shift onto another resource, and what shared capacity does that release? Do not simply draw another line and add its advertised amount without accounting for every resource and receiving condition it still uses.

Contents · Previous chapter · Next chapter

Increase only the shared S-to-H capacity from one hundred to 120 crates. Keep all other conditions unchanged. The original requests can now be met with x = 70, y = 50 and z = 20.

Shared use is 120, A receives seventy and B seventy. The revised cut has capacity 120 + 20 = 140, and the construction delivers 140. Source inventory remains sufficient at 150, and each destination’s eighty-crate receiving ceiling is respected.

This is a conditional improvement in the supplied model. It does not prescribe how a real link should be expanded or whether that change is practical, worthwhile or appropriate. The calculation identifies a relationship whose change would remove this particular obstacle under the stated remaining conditions.

Now contrast increasing the H-to-A route from eighty to 120 while leaving the original shared link at one hundred. The 120-crate source boundary remains. Total delivery still cannot reach 140, and A’s receiving limit is still eighty. Improving a downstream number does not automatically address the limiting service question. A useful proposal states which constraint it changes and demonstrates the resulting feasible allocation.

Contents · Previous chapter · Next chapter

Instead of expanding the shared link, return it to one hundred and increase the direct S-to-B limit from twenty to forty. Choose x = 70, y = 30 and z = 40.

The shared link uses one hundred, A receives seventy and B receives seventy. The revised source-boundary capacity is 140, and the allocation reaches it. This second change meets the same stated destination requirements through a different resource arrangement.

The model has therefore identified two mathematical alternatives. It has not shown that they have the same cost, reliability, environmental effect or operating burden. Those questions require relevant evidence beyond the supplied capacities.

Keep alternatives comparable by preserving the service goal. Comparing one proposal against a 140-crate requirement and another against a lower requirement would obscure what each achieves. Also record what remains unchanged, such as the source inventory and destination limits. If the real proposal changes several conditions at once, represent all of them rather than attributing the whole result to the most visible new route. The strongest explanation connects a proposed change with a reproducible service account.

Contents · Previous chapter · Next chapter

In the original network, suppose the H-to-B link becomes unavailable for the window. Then y = 0. B can receive at most twenty through the direct route, while A can receive at most eighty. Maximum total delivery is therefore one hundred, reached with x = 80 and z = 20.

If the shared S-to-H link is unavailable instead, both hub routes lose their input. Only the direct twenty to B remains possible. A receives zero in this model.

These are named scenarios, not probabilities or a complete reliability assessment. Counting the number of links does not establish how likely either condition is. A real resilience question also needs appropriate dependency, availability and recovery evidence.

The existing Water Security guide on shared dependencies examines why different source names can share a failure condition. Here the main problem is simultaneous capacity allocation even when every original link is available. The two questions connect, but passing one kind of check does not establish the other. A credible report preserves which scenario and which service condition each calculation actually tested.

Contents · Previous chapter · Next chapter

The initial model supplies identical interchangeable crates. A single aggregate flow can therefore track them without preserving several different material classes. Change that assumption and a capacity-only total can become insufficient.

For a separate fictional account, suppose eighty available crates consist of forty suitable only for service A and forty suitable only for B. A requires sixty and B twenty. Total stock equals total requested delivery, but A has only forty compatible crates.

Even with generous route capacity, the sixty-and-twenty request cannot be met under those compatibility rules. Spare B-suitable crates do not satisfy A’s requirement unless an appropriate substitution is explicitly permitted. A successful aggregate movement of eighty would not establish the intended service.

This is a useful limit on a single-commodity model. Units must mean something sufficiently consistent for pooling to answer the question. Do not combine incompatible materials, users or permissions merely because they share a physical route or a common counting unit. The next model may need separate classes and shared-capacity constraints linking their movements. That is a change in what the account must preserve, not a reason to abandon the original simpler example where interchangeability was supplied.

Contents · Previous chapter · Next chapter

Suppose the original hub can process only ninety crates in the window, even though its incoming link permits one hundred. Then x + y ≤ 90 becomes another condition. The direct route still permits twenty.

Maximum total delivery is now at most 110. A feasible allocation is x = 55, y = 35 and z = 20, giving fifty-five to each destination. The shared incoming link uses ninety and therefore has ten units of unused nominal capacity. The hub’s own operation is the tighter resource.

One graph representation separates H into an entry node and an exit node joined by a ninety-capacity processing link. Every movement handled by the hub crosses that link once. This makes the additional limit visible within an ordinary flow account.

The representation should match what consumes the resource. If some movements bypass processing or require several operations, the simple one-crossing model needs revision. A bottleneck can belong to a node, a link, a shared staff task or another operating condition. The mathematical label matters less than accurately accounting for how each proposed delivery uses it. A carefully measured link capacity cannot compensate for an omitted processing constraint.

Contents · Previous chapter · Next chapter

Suppose the first reporting window has the original total transfer limit of 120. A later window can transfer 160 under another supplied arrangement. Their combined capacity is 280, greater than the first window’s 140-crate request.

That two-window total does not establish that all 140 can arrive before the first deadline. Capacity available later cannot satisfy an earlier completion condition unless the task explicitly permits that timing. The original first-window cut still limits first-window delivery.

The opposite mistake is to treat spare capacity in an earlier window as automatically available for pre-delivery. Stock may not yet exist, receiving space may be unavailable or the service may not accept early arrivals. A scheduling model needs those conditions rather than merely moving capacity numbers between columns.

Our static examples intentionally exclude transit and handling time. They answer an allocation question for compatible window quantities. The timed service-visit guide develops a different temporal account. For actual operations, combine appropriate capacity and scheduling evidence; do not allow one mathematically valid summary to make an untested promise about when the whole service can be completed.

Contents · Previous chapter · Next chapter

Consider two identical original-capacity windows. The first receives requests of seventy at A and seventy at B. Deliver sixty to each, leaving ten requested crates outstanding at each destination. The end-of-window backlog is twenty in total.

In the second window, new requests are fifty at each destination. Together with the backlog, the outstanding requirement is sixty at each. The feasible x = 60, y = 40, z = 20 allocation clears all of it by the end of that second window.

Across both windows, requests total 240 and deliveries total 240. Final backlog is zero. Yet the first seventy-and-seventy requests were not fully met by their original deadline. A complete two-window total does not retroactively establish timely first-window service.

The account assumes compatible inventory, permitted carryover and the stated availability for the second window. Those are supplied conditions, not general operating rights. A useful record preserves arrival, required deadline, delivered amount and remaining backlog. It can then distinguish eventually complete, complete within the relevant window and still outstanding. The distinctions are meaningful even when the same final total appears in a summary chart.

Contents · Previous chapter · Next chapter

Suppose the shared capacity is bounded from ninety to 110 and the direct capacity from fifteen to twenty-five, with the other original limits unchanged. Even their largest combined source-boundary capacity is 135. The 140-crate request is infeasible under every permitted combination in this exercise.

For another range, let shared capacity be 110 to 130 and direct capacity fifteen to twenty-five. The lowest combined boundary is 125, while the largest is 155. The source’s 150-crate inventory still caps actual total dispatch, so 155 is only a boundary bound, not an achievable total for the complete network.

The original seventy-and-seventy request is possible under some values. With shared 130 and direct twenty-five, x = 70, y = 45 and z = 25 meets it. With shared 110 and direct fifteen, combined delivery cannot exceed 125, so the request fails.

These bounds therefore do not establish service for every permitted condition. Nor do they assign a probability of success. State whether the claim concerns one feasible case, every case within stated bounds or a statistical model with suitable evidence. Those are different questions, and a favourable endpoint cannot answer them all.

Contents · Previous chapter · Next chapter

Suppose a separate fictional accounting rule assigns a cost of three units per crate using either complete hub route and five per crate using the direct route. These are invented comparable costs for this exercise, not prices or a full social assessment.

For a smaller request of fifty at each destination, x = 50, y = 50 and z = 0 is feasible and costs 100 × 3 = 300 units. A plan with x = 50, y = 30 and z = 20 also meets the requests but costs 80 × 3 + 20 × 5 = 340.

The direct route being unused in the first plan does not make that plan poor. Its spare capacity is unnecessary for the supplied smaller demand, and the objective now includes cost. For sixty at each destination, the full one hundred shared plus twenty direct is needed, costing 400 units under the same rule.

Google’s minimum-cost-flow documentation distinguishes capacity, supply, demand and transport cost in a formal model. Keep those roles separate. A low cost for an infeasible allocation is not a solution, and a maximum-total allocation need not minimise the cost of a specified smaller service requirement.

Contents · Previous chapter · Next chapter

A fresh fictional network has a shared link of seventy-five crates, a hub-to-A limit of sixty, a hub-to-B limit of fifty and a direct-to-B limit of fifteen. Receiving limits are sixty at A and fifty at B; source inventory is 120. Each destination requests fifty.

The source boundary permits at most 75 + 15 = 90, below the combined request of one hundred. The requests are individually feasible but cannot both be met together. A common-fraction allocation sends forty-five to each: x = 45, y = 30 and z = 15. Shared use is seventy-five and total delivery ninety.

Now increase only the direct route to twenty-five. The allocation x = 50, y = 25 and z = 25 meets both requests, uses the original shared seventy-five and respects B’s fifty-crate receiving limit. Increasing only the hub-to-A link would not remove the original ninety-crate source boundary.

For an independent explanation, give the impossibility bound before the improvement and a complete feasible allocation afterwards. Then name one condition the static result leaves unresolved, such as timing or compatibility. The aim is to connect a valid calculation with its actual service meaning, rather than recite that more routes must mean more usable capacity.

Contents · Previous chapter · Next chapter

A useful network account states the service quantities, identities, units, window, inventory, capacities, receiving limits and compatibility assumptions. It distinguishes supplied limits from measured evidence and identifies any conditions not represented by the model.

For checking, trace each route amount through every shared resource. Confirm conservation, destination totals and source use. A claimed maximum needs both a feasible allocation and an appropriate upper bound. A claimed fair, timely or low-cost result needs its own criterion and additional relevant conditions.

The repair route begins with adding contributions to one shared limit. Stabilisation adds two destinations, a bypass and a complete allocation table. Extension adds priorities, processing, time windows and uncertainty. Ask the learner to identify the first missing relationship before assigning a larger network or an optimisation tool.

The Education parent guide connects this approach with independent transfer. Progress appears when the learner can reject an incompatible set of promises, construct a valid alternative and explain which wider decision remains unresolved. A small transparent network can teach that judgement more effectively than a complicated diagram whose resource meanings nobody has checked.

Contents · Previous chapter · Next chapter

If each destination can be served alone, can both be served together?

Not necessarily. Their separate plans may consume the same capacity. Combine the route amounts on one resource ledger and check every simultaneous constraint before combining the service claims.

Does more source stock solve a route bottleneck?

Not by itself. The original source already has 150 crates, while its outgoing boundary permits only 120. More stock would not change that transfer limit under the stated model.

Does maximum total delivery establish a fair allocation?

No. Several allocations can achieve the same total while serving destinations differently. State the allocation rule and the actual destination outcomes. Mathematical feasibility does not determine every real service priority.

Does a capacity allocation guarantee a timetable?

No. Our static account excludes movement durations, handling schedules and other timing conditions. A complete temporal service promise needs an appropriate schedule and supporting evidence as well.

Can a closed final backlog prove every earlier deadline was met?

No. Later deliveries can clear earlier shortfalls. Preserve the arrival and deadline record so eventual completion is not mistaken for timely service in every reporting window.

Are the invented capacities suitable for actual streets or buildings?

No. They are model inputs chosen for learning. Real design, operating and safety decisions require the relevant site conditions, responsible authorities and qualified assessment.

Contents · Previous chapter · Next chapter

Connect the allocation with the urban task

Return to The Gold Standard of Urban Systems. Timed Service Visits develops operating windows and complete visits. Water Security and Shared Dependencies examines another reason that separately named routes may not provide independent service.

Zoning and Unequal Time Windows examines when activities overlap. That temporal evidence can help define which demands actually need simultaneous capacity, before a static allocation model is used.

Study the mathematical mechanism separately

Network Science explains how graph definitions affect conclusions. Edmonds–Karp and Maximum Flow develops an actual solving algorithm, residual choices and a cut certificate. This article’s narrower task is interpreting simultaneous neighbourhood service claims through a small common ledger.

For another solving route, Dinic: Level Graphs and Blocking Flows explains a different maximum-flow algorithm. Mathematics Mastery: Network Flow connects formal constraints with practice. Choose those routes for computation; return here to check whether the computed objective matches the promised neighbourhood service.

Check the primary modelling context

Google’s maximum-flow and minimum-cost-flow documentation supplies formal capacity, conservation and cost context. Source routes checked on 22 October 2026. All Willow Yard resources, demands, allocations and transfer tasks are original hypothetical constructions and do not reproduce the documentation’s worked network.

Continue through How X Works with the service requirement, shared resource and untested conditions still visible. The useful next question is which constraint or missing evidence actually changes the promised outcome.

Contents · Previous chapter · Return to Urban Systems