Skip to content

Flow Channelization

Confine diffuse or chaotic flow into defined channels so it can be directed, measured, protected, or governed.

Version
v1 · 2026-08-24 · History
Solution archetype #
449
Problem family
Congestion, Backlog & Flow Breakdown
Problem subfamily
Routing, Distribution & Endpoint Failure

Essence

Flow Channelization is the intervention of turning diffuse, chaotic, leaking, or hard-to-observe movement into defined pathways. The channel may be a physical lane, a drainage conduit, a service intake path, a data stream, a controlled corridor, or a workflow lane. What makes the pattern an archetype is not the lane or tool itself; it is the structural move from uncontrolled spread to bounded, governable movement.

The channel gives the system a place to direct flow, measure flow, protect adjacent spaces, assign responsibility, and intervene when volume exceeds capacity. The tradeoff is that every channel can become a bottleneck, an exclusion point, or a false symbol of control if overflow, bypass, and accessibility are not designed with the channel.

Compression statement

When diffuse flow is hard to govern or causes spillover harm, channel it through defined pathways to improve control and predictability at the cost of reduced flexibility and channel congestion.

Canonical formula: diffuse_or_leaking_flow + bounded_pathway + entry/overflow/bypass_rules + observability => governable_channelized_flow

When This Archetype Applies

Partial catalog groundingSome structural conditions are represented by existing abstractions, but no sufficient condition set is fully represented.

Diagnostic problem

Flow is diffuse, uncontrolled, or spilling across boundaries, making it hard to direct, measure, or contain.

What this problem means

The structural problem is ungovernable diffusion. Something moves, but it moves through too many paths, across unclear boundaries, or into surrounding systems that are not designed to receive it. Because the movement is diffuse, the system cannot reliably see it, own it, prioritize it, protect it, or repair failures.

Common symptoms include requests arriving in private inboxes instead of a service path, water spreading across streets instead of drains, vehicles of different speeds competing in the same space, data moving through untracked scripts, or sensitive people/materials/events passing through ordinary paths that expose others to risk.

Applicability expression5 distinct conditions

any one(Uncontrolled flow pathsandHarmful spillover)orInterfering flow classesorLatent flow visibilityorBypassed official channels
Algebraic((A∧B)∨C∨D∨E)
A=a∨b
B=B1?B2
B1=a
B2=∅

′ context guard? connective not recorded∅ no catalog witness yet

groundedpartly groundedopen

5 conditions, all required.

4At least one of theselettered A–E

Any one of these groups completes the pattern; conditions inside a group are required together.

A

Uncontrolled flow paths · grounded · any one of 2

Flow spreads through many informal or uncontrolled paths.

a

domainAlluvial Fan— The fan-shaped sediment landform built where a confined, sediment-laden channel exits a steep upland at a slope break, loses transport competence, and deposits its load coarse-to-fine as successive lobes avulse radially around the apex.

b

domainKarst— Diagnose a landscape where acidic groundwater has dissolved soluble bedrock into a self-reinforcing hidden conduit network, so the surface no longer maps the subsurface drainage and porous-media terrain rules are suspended.

How this was matched — 2 shared + 2 branches

Flow disperses across many informal or uncontrolled paths.

All of

  • roleA quantity, signal, material, or comparable flow moves through a path-bearing system.
  • quantifierThe flow spreads through many distinct paths.

…and any one of

  • branchThe many paths are informal or not formally defined as channels.
  • branchThe many paths are uncontrolled or not subject to effective direction or containment.
B

Harmful spillover · 2 cases · 1 matched

Spillover damages1 adjacent systems or creates2 safety, fairness, privacy, or environmental risk.

This predicate enumerates 2 cases · 1 matched

  • 1

    Spillover causes actual damage to an adjacent system.

    matched to the catalog

    Established by

    domainImputation Leakage— The model-evaluation failure in which a missing-value repair step is fit across the train/test boundary, so its parameters encode facts about the held-out rows — inflating performance that survives into the test metric, because imputation, mentally filed as data cleaning, is really a model.

    Case 1 of 2 — what it requires — 4 requirements, all needed

    All of

    • roleThe roles are spillover from a focal flow and a distinct affected system.
    • domainThe affected system is adjacent to the source or channel of the spillover.
    • causalityThe spillover causes damage to the adjacent system.
    • modalityDamage to the adjacent system has actually occurred rather than remaining a possibility or risk.
  • 2

    Spillover creates risk in a specified protected domain.

    no catalog match yet

    Nothing in the catalog establishes this case yet

    Case 2 of 2 — what it requires — 3 shared + 4 branches

    All of

    • roleSpillover from a focal flow exposes a system, population, information context, or environment to risk.
    • causalityThe spillover creates the risk.
    • modalityThe outcome is exposure to possible harm rather than necessarily completed harm.

    …and any one of

    • branchThe spillover creates safety risk.
    • branchThe spillover creates fairness risk.
    • branchThe spillover creates privacy risk.
    • branchThe spillover creates environmental risk.
Within a case the abstractions are alternatives — any one establishes it. How the 2 cases combine with each other is not recorded in the source; the predicate reads as an alternation, but polarity can flip that reading, so it is marked ? above rather than guessed.
C

Interfering flow classes · open

Multiple flow classes interfere with one another.

D

Latent flow visibility · open

Important flow remains invisible until after failure.

E

Bypassed official channels · 4 cases · 0 matched

Official channels are bypassed because they are unclear, overloaded,2 inaccessible,3 or mistrusted.4

Coverage

1 of 5 conditions grounded · 1 partly grounded · 3 open.

None of the 3 open conditions sit in the shared core — each falls inside one alternative branch, so grounding any one of them closes only that branch.

Read the methodologyDownload the trigger-logic data

When to Use This Archetype

Use this archetype when important flow is arriving through too many informal paths, spreading into spaces that cannot safely absorb it, or remaining invisible until failure. It is especially useful when mixed flows interfere with each other, when spillover harms adjacent systems, or when service, data, water, traffic, or case movement needs a clear path before it can be governed.

Do not use it merely because something can be put in a lane, queue, or portal. Use it when the intervention changes the structure of movement: diffuse flow becomes channeled flow with boundaries, entry rules, observability, capacity assumptions, overflow policies, and exit conditions.

Structural Problem

The structural problem is ungovernable diffusion. Something moves, but it moves through too many paths, across unclear boundaries, or into surrounding systems that are not designed to receive it. Because the movement is diffuse, the system cannot reliably see it, own it, prioritize it, protect it, or repair failures.

Common symptoms include requests arriving in private inboxes instead of a service path, water spreading across streets instead of drains, vehicles of different speeds competing in the same space, data moving through untracked scripts, or sensitive people/materials/events passing through ordinary paths that expose others to risk.

Intervention Logic

The intervention starts by naming the flow: what is moving, why its unchanneled form matters, and what must be preserved as movement becomes constrained. Then it defines a channel boundary and path. The path must be clear enough to guide movement and real enough to change behavior, not merely a diagram.

Next, the design sets entry, exit, overflow, and bypass rules. These rules prevent the channel from becoming a dumping ground, a hidden queue, or an exclusionary gate. Finally, the channel is instrumented: volume, waiting time, leakage, congestion, and exception patterns are monitored so the channel can be tuned rather than treated as a fixed artifact.

Key Components

Flow Channelization converts diffuse, leaking, or unobservable movement into bounded, governable pathways. The intervention starts by naming the Diffuse Flow Signature — what is moving (water, work, requests, people, data, vehicles, attention) and what harm its current diffuse form causes through collision, spillover, invisibility, delay, or contamination. The Channel Boundary is the edge that separates inside from outside, whether physical, procedural, legal, digital, or organizational — without a real boundary there is only an aspiration that flow should move somewhere. The Path Definition describes where flow enters, how it moves, where it may branch, and where it exits, making the channel legible to users, operators, and reviewers. An Entry Rule determines what belongs in the channel and what preparation must occur before flow enters, keeping the channel from becoming an unstructured dumping ground.

Three components make the channel observable and tunable rather than treating it as a fixed artifact. A Flow Observability Point is where the system can see channel health — volume, waiting time, state, quality, leakage, overload, or exception patterns — so that governance is architecturally available rather than bolted on. A Channel Capacity Profile states how much the channel can safely or fairly carry, turning overload from a vague complaint into a measurable condition. A Congestion Relief Trigger specifies when to widen, split, staff, reroute, or throttle the channel so it does not become a permanent chokepoint.

Two policy components handle the channel's edge cases, which are usually where the design lives or dies. An Overflow Policy defines what happens when capacity is exceeded — buffering, diversion, splitting, throttling, escalation, or movement to a surge channel — because channelization concentrates flow and thereby raises the stakes of planned overload handling. A Bypass Policy distinguishes legitimate exceptions (emergencies, accessibility, edge cases) from harmful evasion that restores invisible, unaccountable movement; repeated bypass should be read as design evidence rather than misconduct. Finally, an Exit Condition defines how flow leaves the channel and what must be true at exit, preserving accountability whether work is released or handed to the next channel.

ComponentDescription
Diffuse Flow Signature ↗The diffuse flow signature identifies what is moving and why its current form is hard to govern. A useful signature says whether the flow is water, people, work, data, requests, vehicles, materials, attention, or responsibility. It also states the harm caused by diffusion: collision, spillover, invisibility, delay, privacy risk, accountability loss, or contamination.
Channel Boundary ↗The channel boundary is the edge that separates inside from outside. It may be physical, procedural, legal, digital, visual, or organizational. Without a boundary, there is no channel; there is only an aspiration that flow should move somewhere. The boundary should constrain movement without making legitimate movement impossible.
Path Definition ↗The path definition describes where the flow enters, how it moves, where it may branch, and where it exits. A channel can be a lane, conduit, portal, queue, corridor, stream, service path, or workflow swimlane. The path definition makes the channel legible to users, operators, and reviewers.
Entry Rule ↗The entry rule determines what belongs in the channel and what must happen before flow enters it. Entry rules may specify categories, formats, eligibility, labeling, intake evidence, or preparation requirements. They keep channels from becoming unstructured dumping grounds.
Flow Observability Point ↗An observability point is where the system can see channel health. It may measure volume, waiting time, state, quality, leakage, overload, or exception patterns. Because one reason to channelize flow is to make it governable, observability belongs in the architecture rather than as an afterthought.
Channel Capacity Profile ↗The capacity profile states how much the channel can safely or fairly carry. It turns overload from a vague complaint into a measurable condition. Without a capacity profile, channelization may simply concentrate chaos into one visible bottleneck.
Overflow Policy ↗The overflow policy defines what happens when the channel cannot absorb more flow. Overflow may be buffered, diverted, split, throttled, escalated, or moved to a surge channel. This component is crucial because channelization increases the importance of planned overload handling.
Bypass Policy ↗The bypass policy distinguishes legitimate exceptions from harmful evasion. Some bypass is necessary for emergencies, accessibility, edge cases, or safety. Other bypass undermines the channel by restoring invisible, unaccountable movement. A good bypass policy treats repeated bypass as design evidence.
Congestion Relief Trigger ↗The congestion relief trigger specifies when to widen, split, staff, reroute, throttle, or otherwise relieve the channel. It prevents the channel from becoming a permanent chokepoint. Relief triggers are often tied to volume, waiting time, failure rate, risk, or leakage.
Exit Condition ↗The exit condition defines how flow leaves the channel and what must be true at exit. It prevents movement from being trapped or released without responsibility. Exit conditions also preserve accountability when flow leaves one channel and enters another.

Common Mechanisms

Traffic lanes implement channelization in physical movement systems by separating flow classes and reducing collision. They are mechanisms, not the archetype, because the same channelizing logic appears in non-traffic domains.

Drainage channels and spillways confine water or material flow so it can be directed away from vulnerable areas. They show the containment and overflow side of the archetype.

Intake queues, ticketing systems, and service portals channel diffuse requests into a path with ownership, status, prioritization, and escalation. These tools fail when they merely collect requests without creating a governed path after entry.

Workflow swimlanes represent or enforce separate channels of responsibility. They can reveal where work crosses teams, where ownership is unclear, and where flow leaks between categories.

Data conduits, message buses, and controlled data streams channel information through defined interfaces. Their value is not just technical transport; it is observability, validation, security, and failure handling.

Controlled corridors implement safety-sensitive channelization. They allow necessary movement while protecting adjacent systems from exposure, contamination, conflict, or uncontrolled spread.

Dashboards and channel monitoring tools observe channel health. They support the archetype but do not replace the channel; a dashboard without a governed path only visualizes disorder.

10 documented mechanisms across 6 implementation forms.

The grouping reflects forms represented among the mechanisms currently documented for this archetype; an absent form is not necessarily an impossible implementation.

Control, Automation & Runtime · 3 mechanisms

  • Controlled Corridor — Holds open one protected, admission-controlled passage between the closing zone and the destination, and keeps proving it is passable end to end while the space around it constricts.
  • Intake Queue — Holds admitted work in an ordered, priority-ranked line with explicit rules for who advances, who may legitimately jump, and what 'done' means, so nothing waits invisibly or forever.
  • Overflow Lane or Spillway — A normally-dormant surge path that opens only when the primary channel exceeds its capacity, carrying the excess along a planned route instead of letting it back up or spill.

Interface, Display & Cue · 1 mechanism

  • Service Channel Portal — One official front door that consolidates scattered requests behind a single governed intake, with defined submission requirements and an accessible alternate for those the standard path would exclude.

Monitoring, Sensing & Alerting · 1 mechanism

  • Channel Monitoring Dashboard — Puts a channel's health — volume, load against capacity, and leakage — on one live surface, so overload is seen and acted on rather than discovered at failure.

Record, Log & Register · 1 mechanism

  • Ticketing System — Turns each incoming request into a durable, owned, trackable record that moves through states from open to resolved, so nothing is lost and everyone can see where it stands.

Representation, Specification & Plan · 1 mechanism

  • Workflow Swimlane — A design diagram that assigns each strand of work to its own responsibility lane and exposes exactly where flow crosses a boundary or leaks between owners.

Structure, Architecture & Configuration · 3 mechanisms

  • Data Conduit — Moves information through one defined stream that validates what enters and confirms what is delivered, replacing untracked point-to-point scripts with a governed, observable path.
  • Drainage Channel — Confines diffuse runoff inside bounded banks and directs it along a rated path to a safe discharge, so it flows where intended instead of spreading into vulnerable ground.
  • Traffic Lane — Separates incompatible flow classes into their own bounded routes, admitting only eligible traffic and granting priority classes a dedicated lane, so faster and slower movement stop colliding.

Parameter / Tuning Dimensions

Important tuning dimensions include channel width, capacity, permeability, entry strictness, exit strictness, flow-class separation, monitoring density, overflow threshold, bypass legitimacy, accessibility support, and congestion relief speed.

A wider channel can reduce congestion but may admit too much unfiltered flow. A stricter entry rule can improve quality but may exclude edge cases. Stronger boundaries can improve containment but increase bypass pressure. More monitoring can improve governance but may create surveillance or administrative burden.

Invariants to Preserve

The first invariant is that movement remains possible. Channelization is not immobilization; the channel should make flow governable while preserving legitimate motion.

The second invariant is legibility. Flow should not lose identity, state, ownership, or status merely because it enters a channel.

The third invariant is protection of adjacent systems. If the channel simply moves spillover into less visible places, it has failed.

The fourth invariant is governed exception handling. Emergencies, accessibility needs, and edge cases should have legitimate paths rather than being forced into shadow channels.

The fifth invariant is visible capacity. A channel should reveal overload rather than hide it.

Target Outcomes

Successful Flow Channelization improves observability, routing reliability, safety, containment, accountability, and operational coordination. It reduces uncontrolled spillover and makes congestion easier to detect. It also makes ownership clearer: flow inside a channel can be assigned, measured, escalated, or released under explicit conditions.

The best outcome is not maximum control. The best outcome is movement that is sufficiently bounded to govern and sufficiently flexible to remain usable under real conditions.

Tradeoffs

Channelization trades flexibility for governability. It can create visibility, but that visibility comes from concentrating flow and therefore may produce bottlenecks. It can improve safety, but strong channel boundaries may reduce accessibility. It can standardize intake, but standard intake may misfit unusual cases.

Another tradeoff is trust. Users will use a channel when it is legitimate, usable, and effective. If the official channel is slow, inaccessible, or punitive, people create shadow channels and the system loses both control and visibility.

Failure Modes

Channel congestion occurs when too much flow is forced into a path with insufficient capacity. The mitigation is to monitor load, define relief triggers, add overflow paths, or split flow classes.

Brittle over-channelization occurs when all movement is forced through one rigid path. The mitigation is to design exceptions and adapt the channel to recurring edge cases.

Shadow-channel formation occurs when people bypass the official path because it is slower, harder, or less trusted than informal routes. The mitigation is to study bypass behavior as evidence about channel fit.

False control occurs when a channel exists on paper while flow continues leaking outside it. The mitigation is leakage detection and comparison between expected and observed flow volumes.

Channel capture occurs when high-power or high-volume users dominate the pathway. The mitigation is priority policy, reserved capacity, equity review, or separate channels for incompatible flows.

Hidden externalization occurs when overflow is pushed into other systems without being counted. The mitigation is explicit overflow destinations and accountability for downstream burden.

Neighbor Distinctions

Flow Channelization is distinct from Flow Diversion or Rerouting because rerouting changes the path of flow that already has a path. Channelization creates or formalizes the path itself.

It is distinct from Gateway Mediation because a gateway controls entry at a point, while channelization governs movement along a pathway.

It is distinct from Boundary Permeability Control because permeability decides what crosses an edge, while channelization uses boundaries to create a path.

It is distinct from Queueing because queueing governs waiting and service order. A queue can be a mechanism of channelization, but the archetype is broader.

It is distinct from Pipeline Staging because a pipeline divides work into ordered transformation stages. A channel can simply guide movement without transforming the item through stages.

It is distinct from Load Balancing because load balancing distributes burden across capacity. Channelization may concentrate, separate, contain, or reveal flow; it does not necessarily balance it.

Cross-Domain Examples

In urban drainage, gutters and spillways channel water away from vulnerable areas. The channel must have capacity and overflow design, or it simply moves flooding elsewhere.

In transportation, dedicated bus, bicycle, pedestrian, or emergency lanes separate movement classes that would otherwise interfere with each other.

In customer support, a ticketing system channels scattered requests into a visible pathway with categories, owners, status, and escalation.

In data engineering, a message bus channels events through a monitored conduit rather than allowing unmanaged scripts to send data everywhere.

In public health, a clinic may channel potentially infectious patients through a distinct intake and movement corridor to reduce exposure while preserving care.

In team operations, separate intake paths for incidents, feature requests, and compliance evidence keep different work flows from colliding in one informal stream.

Non-Examples

Assigning tickets to a different employee after they already entered the ticket system is not Flow Channelization; that is routing or load balancing inside an existing channel.

Checking IDs at a door is not enough; that is gatekeeping unless it defines a governed path after entry.

Dividing production into ordered stages is Pipeline Staging, not Flow Channelization, when the central logic is transformation through stages.

Choosing first-in-first-out or priority order inside a line is Queue Discipline, not Flow Channelization, unless the main intervention is creating the line or pathway itself.

Drawing arrows on a process diagram is not channelization unless the arrows change how flow actually enters, moves, exits, overflows, or bypasses.

Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.

Built directly on (3)

  • Boundary: Defines system limits.
  • Constraint: Limits possibilities to guide outcomes.
  • Flow: Structured movement of energy, matter, or information.

Also references 2 related abstractions

  • Network: Models interactions between components.
  • Pipeline: Sequential processing stages.

Variants

Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.

Intake Channelization · subtype · recognized

A variant where diffuse requests, arrivals, reports, cases, or applications are routed into a defined intake path before work begins.

  • Distinct from parent: The parent can channel any flow; this subtype emphasizes first-entry capture and normalization.
  • Use when: Requests or arrivals enter through too many informal paths; Context, ownership, priority, or evidence is lost before handling starts; The system needs an explicit entry point without necessarily imposing a full staged pipeline.
  • Typical domains: customer support, incident reporting, benefits applications, clinical triage
  • Common mechanisms: intake queue, ticketing system, service channel portal

Lane-Based Channelization · domain variant · recognized

A variant where movement is separated into lanes by direction, speed, class, priority, or protected use.

  • Distinct from parent: The parent includes conduits, intake paths, queues, and corridors; lane-based forms emphasize parallel separation of flow streams.
  • Use when: Mixed flow creates collision, interference, delay, or ambiguity; Different flow classes need different speeds, protections, or rules; The system can preserve safety or predictability by separating streams.
  • Typical domains: transportation, warehouse operations, hospital patient flow, digital workflow boards
  • Common mechanisms: traffic lane, workflow swimlane, controlled corridor

Containment Corridor · risk or failure variant · recognized

A variant where the channel exists primarily to contain hazardous, sensitive, disruptive, or high-risk flow away from vulnerable surroundings.

  • Distinct from parent: The parent may channel flow for measurement, routing, or service; this subtype focuses on preventing harmful escape or exposure.
  • Use when: Uncontrolled spillover creates safety, privacy, contamination, conflict, or environmental risk; The flow must move, but only through a protected or monitored corridor; Adjacent systems need protection from leakage, contact, or uncontrolled diffusion.
  • Typical domains: infection control, hazardous material movement, secure data handling, wildlife crossings
  • Common mechanisms: controlled corridor, drainage channel, data conduit

Data-Conduit Channelization · domain variant · recognized

A variant where information flow is confined to defined data paths, streams, APIs, buses, or queues so it can be validated, monitored, secured, or routed.

  • Distinct from parent: The parent is medium-neutral; this variant focuses on data-specific validation, provenance, security, and observability concerns.
  • Use when: Information currently spreads through ad hoc channels that lose provenance, security, or reliability; The system needs predictable interfaces and monitoring for data movement; Sensitive or operationally critical data must not diffuse through uncontrolled paths.
  • Typical domains: software integration, data engineering, security operations, reporting pipelines
  • Common mechanisms: data conduit, ticketing system, channel monitoring dashboard

Overflow Channelization · risk or failure variant · recognized

A variant where excess flow is given a planned spillway, overflow lane, surge queue, or fallback channel instead of spilling into uncontrolled space.

  • Distinct from parent: The parent includes ordinary channel creation; this subtype designs the emergency or surge channel specifically.
  • Use when: Normal channels periodically exceed capacity; Unplanned overflow causes damage, unfairness, hazard, or loss of visibility; A secondary pathway can preserve minimum service, safety, or containment during surge.
  • Typical domains: stormwater management, emergency departments, digital service queues, customer support surge handling
  • Common mechanisms: overflow lane or spillway, channel monitoring dashboard, intake queue

Source Local Service Channel Disturbance · implementation variant · recognized

Convert unavoidable functional interstices into service channels that act directly at the source, and generate disturbance locally only where it improves transfer.

  • Distinct from parent: Unavoidable interstices are converted into service channels at the disturbance source, with additional turbulence generated only where it improves exchange. Existing intake, lane, corridor, data, and overflow variants do not preserve source locality or bounded disturbance.
  • Use when: High power density is limited by heat generated inside narrow winding and magnet regions that are poorly served by remote cooling jackets.
  • Evidence (strong independent recurrence confirmed): US12166384B2; NASA impingement cooling channels at heat sources; Effusion cooling through functional interstices

External-Runoff/Internal-Condensate Route Separation at a Penetration · implementation variant · recognized

At an enclosure penetration, direct external liquid around the opening with graded channels while wicking internally generated condensate through a controlled outlet that still blocks bulk outside-air entry.

  • Distinct from parent: Two water sources meeting one penetration receive distinct collection and discharge paths so neither can backfeed the other. Existing flow-channelization siblings do not preserve source-specific routing at a shared boundary or bypass, blockage, and cross-route leakage failures.
  • Use when: A transparent penetration faces both exterior runoff intrusion and interior condensation, which originate on opposite sides of the boundary.
  • Evidence (strong independent recurrence confirmed): US4776141A; NASA — Separate rain-catch and internal condensate drainage with no communication

Contrasting-Wettability Passive Liquid Routing · surface energy channel variant · recognized

Place liquid-rejecting and liquid-accepting regions side by side so their surface-energy boundary passively confines and directs liquid along the wetting path.

Near names: Flow Channelling, Lane Design, Conduit Design, Intake Channel, Service Channel, Channel Routing.

Editorial Notes

Problem Classification

Classification: Congestion, Backlog & Flow Breakdown → Routing, Distribution & Endpoint Failure

Problem kernel: diffuse flow lacks a usable directed path through the topology

Rationale: Diffuse movement lacks a defined path, so flow cannot be directed, measured, protected, or delivered reliably through the topology. Spillover is present, but the evidence does not require movement between two distinct regimes or a specific crossing surface; the more general causal center is absence of a usable route that concentrates movement without stopping it.

Boundary considered: Boundary, Scope, Access & Spillover Failure → Crossing, Interface & Edge-Zone Failure

Why this classification prevailed: Routing failure concerns whether flow has an effective distribution path; crossing failure requires a poorly governed interface between distinct regimes that admits or blocks the wrong exchange.

Review outcome: Adjudicated after independent review; high confidence.