Skip to content

Connectivity or Corridor Plan

Connectivity plan — instantiates Source–Sink Viability Management

Designs and protects the actual pathways along which a source's surplus can reach a sink, and deliberately keeps more than one route open, so rescue can happen without leaving the sink hostage to a single link.

A Connectivity or Corridor Plan builds and guards the links of the system rather than its patches: the routes along which surplus, dispersers, or support physically travel from a source to a sink. Its defining idea is that a source can only rescue a sink it can reach — connectivity is the precondition for the rescue effect, so if the pathway is thin, unreliable, or singular, the surplus never arrives and a viable source and a recoverable sink still fail as a pair. It is not a flow-optimizer chasing maximum throughput; it is a viability plan that asks which links keep a sink above water, how reliable they are, and how many independent ones exist — and it treats a second route to a second source as a feature, not redundancy to be trimmed.

Example

A rural clinic (a demographic sink for specialist care — it consumes more expertise than it can generate locally) survives on referrals to a distant city hospital. On paper the referral pathway exists, so the clinic "has access." A connectivity plan looks harder: the single mountain road closes in winter, the one partner hospital is often at capacity, and the telemedicine link drops on the clinic's aging connection. The plan maps these routes explicitly, then acts on the map — it adds a second referral hospital in a different direction, hardens the network link the telemedicine consults ride on, and pre-arranges winter transport.

The outcome is not more throughput but more reliable reachability: the clinic can now draw specialist support from either of two sources over either of two channels, so a closed road or a full ward no longer severs it. The clinic is no different internally — it is still a sink — but it is no longer one storm away from isolation.

How it works

  • Identify the rescue-bearing links, not all links. Map only the source→sink pathways that actually carry viability-critical surplus, with their capacity and, crucially, their interruption risk.[1]
  • Design for independence, not just capacity. Ensure a sink can be reached by more than one source over more than one route, so no single failure isolates it — the multi-source move that distinguishes this from a single fat pipe.
  • Protect the pathway. Secure the corridor against the specific things that sever it (a road, a bandwidth budget, a contractual right-of-way), because an unprotected link degrades silently until the day rescue is needed.
  • Preserve asymmetry and independence deliberately. Connect enough for rescue to flow, but not so much that distinct patches fuse into one pool where a shock in one spreads to all.

Tuning parameters

  • Route redundancy — how many independent source→sink paths to maintain. More paths cut isolation risk but cost capital and attention; set it by how catastrophic a cutoff would be.
  • Capacity vs. reliability — a fat but fragile corridor versus a thinner, dependable one. For rescue, reliability usually beats peak capacity.
  • Coupling strength — how tightly connected the patches become. Turn it up for stronger rescue; turn it down to stop shocks and contagion propagating between patches.
  • Protection level — how hard the corridor is defended against severance, from best-effort to guaranteed right-of-way.

When it helps, and when it misleads

Its strength is preventing the quiet failure where a perfectly good source cannot rescue a recoverable sink because the link between them is thin or singular; it converts "access exists" into "support arrives, even under stress." Building in a second source is what turns a fragile lifeline into a resilient one.

Its failure modes come from mistaking it for a throughput problem. Optimize purely for flow and you over-couple the network — patches fuse, local distinctness is lost, and a shock or contagion in one site now races to all of them, the opposite of viability. It can also gold-plate corridors nobody uses while the truly load-bearing link stays fragile, or be run backwards to justify a route already chosen for other reasons. The discipline is to size and protect corridors by the rescue they carry and the isolation they prevent — not by maximum flow — and to keep patches independent enough that connection helps them survive without making them fail together.

How it implements the components

Connectivity or Corridor Plan realizes the pathway-design slice of the archetype — the components about the routes support travels and how many there are:

  • connectivity_pathway_map — its primary artifact: the map of which source→sink links exist, their capacity, and their interruption risk.
  • multi_source_diversification_plan — the explicit design that a sink be reachable from several independent sources, so no single severance isolates it.

It designs the pathways but does not measure what actually moves along them — that is the Dispersal or Transfer Tracer; it does not decide whether a given sink is worth connecting to at all — that judgment is the Restoration Priority Matrix; and it does not budget the surplus the corridor carries — that is the Cross-Subsidy Budget.

Notes

More connectivity is not monotonically better. Past the point where rescue is assured, extra coupling mainly transmits shocks — a disease, a demand spike, a failure — from patch to patch, so a good plan connects enough to rescue and then stops, keeping firebreaks between sites that must be able to fail alone.

References

[1] In landscape ecology, habitat corridors sustain the rescue effect — immigration that keeps a local population from going extinct — but only when the corridor is actually usable; a mapped-but-impassable link provides no rescue. The same "reachable, not just present" test applies wherever a source must reach a sink. ↩