Skip to content

Reachability Test

Acceptance test — instantiates Spanning Connectivity Formation

Checks that every required endpoint pair can actually reach each other over a usable path, turning 'looks connected' into a pass/fail verdict against a stated spanning criterion.

A network can be topologically joined and still fail the job it was joined for. Reachability Test takes the set of endpoints that are required to reach one another, probes whether a usable path actually exists between them each way, and returns a pass/fail verdict against an explicit spanning criterion. Its defining move is the word usable: a path that exists on the map but is too slow, too lossy, too expensive, or too indirect to serve the function counts as a fail, not a pass. Where a component scan answers "how many islands?", this test answers the sharper question the decision actually hangs on — "can the endpoints that matter reach each other well enough?"

Example

A transit authority opens a new interchange and wants to confirm that every outlying district can now reach the central hospital district. The reachability requirement is the set of district-to-hospital pairs; the path-quality floor is "no more than two transfers and 45 minutes." Topologically, every district connects — so a naïve check would pass. The test does not: three outer districts reach the hospital only via three-transfer, seventy-minute routes, which fall below the floor. The verdict is FAIL on quality for three pairs, and it sends planners back to add one express link rather than declaring victory on a network that is connected but unusable where it counts.

How it works

The distinguishing discipline is that the test is requirement-scoped and quality-gated. It does not check all pairs — it checks the declared reachability domain, the endpoints that must connect for the function to work. For each required pair it confirms a path exists in the needed direction(s) and that the path clears the quality floor; a path below the floor is treated as no path. The pass condition is the stated spanning criterion (for example, "all critical origin-destination pairs reachable within the floor"), and the output is a verdict plus the specific pairs that failed and why.

Tuning parameters

  • Required-pair set — all-pairs versus a curated set of critical origin-destination pairs. Narrowing to what truly must connect makes the test both cheaper and more honest.
  • Path-quality floor — the bar a path must clear (latency, hops, capacity, cost, reliability). Raising it fails more marginal paths and demands a stronger network.
  • Directionality — whether reachability must be mutual or one-way suffices for the function.
  • Coverage of probing — exhaustive verification versus sampling representative pairs, trading assurance against cost.
  • Retest cadence — one-time acceptance versus re-testing after every change to the network.

When it helps, and when it misleads

Its strength is that it catches the failure mode a topology check misses — connected but unusable — and converts a subjective "seems fine" into an unambiguous gate tied to the endpoints that matter.[1]

Its central blind spot is that a pass certifies reach today, not resilience tomorrow: a single fragile path can pass the test and be severed the next day, so reachability is not robustness — that belongs to Cut-Set Hardening and Redundant Network Link. The classic misuse is running it backwards: quietly relaxing the quality floor until a marginal network passes, converting the test from a check into a rubber stamp. The discipline is to freeze the required-pair set and the floor before testing, report failing pairs rather than a single green light, and pair the pass with a robustness check.

How it implements the components

Reachability Test realizes the acceptance-criterion side of the archetype — the components that define and verify the required end state:

  • target_reachability_domain — it fixes which endpoints are actually required to reach one another; the test is scoped to these, not to all pairs.
  • spanning_connectivity_criterion — it states and evaluates the explicit pass condition for the whole required set.
  • path_quality_floor — it enforces the usability bar, disqualifying paths that exist but are too poor to serve the function.

It does not produce the descriptive component baseline (that is Connected-Component Scan) nor establish resilience against failures (that is Cut-Set Hardening); it verifies reach, it does not create or harden it.

References

[1] In reliability theory, k-terminal reachability asks whether a specified set of terminal nodes can all reach one another through the network — the same requirement-scoped question this test operationalizes, rather than checking every possible pair. ↩