Reroute and Reentry Protocol¶
Protocol — instantiates Outcome-Attractor Pathway Design
Specifies how a case, user, workflow, or subsystem moves from a failing path back into an admissible route.
A Reroute and Reentry Protocol is the standing procedure for what happens after a route has failed: how a stranded case is caught, which admissible route it is moved onto, what state it re-enters at, and who is accountable for the move. Its defining move is recovery action — where detection notices that a case has left the basin, this protocol is the machinery that carries it back in, choosing a substitute route and re-establishing the case inside a valid path rather than abandoning it as a failed exception. It presupposes both that a divergence has been detected and that a set of admissible routes exists; its own job is the transition between them. It is the archetype's answer to "a route can fail without the actor being abandoned."
Example¶
A consumer-lending operation processes loan applications toward one endpoint: a funded loan or a clean, explained decline. Applications flow down an automated fast-track route, but some stall — a thin credit file the model can't score, a mismatched address that trips verification, an income source the automation doesn't recognize.
The Reroute and Reentry Protocol governs the rescue. When an application trips a stall condition, the protocol specifies the reentry: the case is packaged with its progress so far, moved onto the manual-underwriting route (a substitute route that can handle the exception), and re-enters at the verification step rather than restarting from zero. The protocol names who owns the handoff, what state the case must be in to be accepted by the manual route, and a time bound after which an un-rerouted case escalates. Because the substitution is governed rather than improvised, the thin-file applicant reaches the same endpoint by a different admissible route — the system degrades gracefully[1] instead of dead-ending the application. What it does not do is decide the stall threshold; that trip-wire is set and watched elsewhere.
How it works¶
- Trigger on a detected divergence. The protocol activates from a signal that a case is stuck or out of basin; it does not itself scan for trouble.
- Select a substitute route. It applies the substitution policy to pick which admissible route the case moves onto, given why the current one failed.
- Preserve and re-anchor state. The case is carried over with its progress intact and re-entered at a defined, valid point in the new route — not restarted, not lost.
- Assign ownership and a time bound. Every reroute names who is responsible and by when, with an escalation path if reentry itself stalls, so recovery is accountable rather than aspirational.
Tuning parameters¶
- Reentry generosity — how many failures a case may recover from before being escalated or terminated. Generous reentry rescues more cases but can trap resources in ones that will never converge.
- Reentry point — where in the substitute route a rerouted case resumes. Re-entering late preserves prior effort but risks importing a defect; re-entering early is safe but wasteful.
- Substitution breadth — how many alternate routes a failure may be moved onto. Broad substitution maximizes recovery but complicates governance and equivalence testing; narrow substitution is simple but can strand certain failures.
- Time bound — how long a case may sit mid-reroute before escalation. Tight bounds keep cases moving but generate escalations; loose bounds risk silent limbo.
- Automation level — whether reroutes fire automatically or require human sign-off. Automatic reroutes are fast and consistent but can loop; human sign-off is careful but slow.
When it helps, and when it misleads¶
Its strength is that it makes failure recoverable and governed: instead of a stalled case becoming an improvised one-off (and a stigmatized exception), it moves through a named door onto a real alternate route, preserving the actor's progress and the endpoint's reach. It is what lets a multi-path system tolerate route failure without lockout.
Its failure mode is the reroute loop and the laundering of bad cases: a poorly bounded protocol can shuttle a case between routes indefinitely, each move looking like progress while nothing converges, and a too-generous reentry can move a case that violates an invariant onto a new route rather than stopping it — using reroute to bypass a guardrail instead of respecting it. The classic misuse is treating reroute as a pressure valve that quietly relabels failures as "in progress." The guarding discipline is to cap reentries, to re-check invariants at each reentry (an informal gate, not a full equivalence test) so reroute never launders a case past a non-negotiable, and to escalate rather than re-loop once the cap is hit.
How it implements the components¶
divergence_boundary_and_reentry_rule— it implements the reentry half of the rule: the governed procedure by which an out-of-basin case is corrected and returned to a valid path.route_substitution_policy— it applies the policy that decides which admissible route a failing case is moved onto and on what terms.admissible_pathway_set— reentry always targets a route from the admissible set, so recovery restores a case into a governed path rather than an ad-hoc one.
It does not detect the divergence or set the stuck-threshold in the first place (path_progress_observability) — that is Pathway Health Dashboard — nor author the authoritative register of which routes are admissible (that register is Admissible Pathway Catalog's; this protocol consumes it).
Related¶
- Instantiates: Outcome-Attractor Pathway Design — the protocol is the reentry machinery that keeps route failures recoverable and convergence reachable.
- Consumes: Pathway Health Dashboard supplies the divergence-detection signal that triggers a reroute; Admissible Pathway Catalog supplies the set of routes a case may re-enter.
- Sibling mechanisms: Admissible Pathway Catalog · Attractor Basin Simulation · Endpoint Equivalence Test Suite · Guided Multi-Path Onboarding Flow · Multi-Route State-Transition Map · Normalized Endpoint Contract · Pathway Cohort Comparison · Pathway Health Dashboard
Editorial Notes¶
Form Classification¶
Form family: Protocol, Workflow & Routine
Rationale: Reroute and Reentry Protocol operates as a repeatable ordered procedure or handoff sequence that coordinates action because it specifies how a case, user, workflow, or subsystem moves from a failing path back into an admissible route.
Independent corroboration: The frozen evidence defines Reroute and Reentry Protocol as 'Specifies how a case, user, workflow, or subsystem moves from a failing path back into an admissible route', so its operative form is Protocol, Workflow & Routine.
Nearest alternative: Decision, Gate & Allocation — Reroute and Reentry Protocol includes features of a case-specific gate, selection, routing, prioritization, or resource disposition, but its defining operation is a repeatable ordered procedure or handoff sequence that coordinates action.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: Case and workflow management routes records through admissible paths and can resume a suspended or failed process from preserved state; organizational process design generalizes that logic beyond software.
Related originating lineages:
- Computer Science & Software Engineering — computer_science contributes software, workflow, data-structure, and automation practice to the mechanism’s formative or independently convergent form; that contribution does not displace the primary organizational_management lineage.
- Public Administration & Policy — public_administration_policy contributes program oversight, implementation, and public accountability to the mechanism’s formative or independently convergent form; that contribution does not displace the primary organizational_management lineage.
Review resolution: The blind reviewers disagreed on primary lineage; authoritative research supports organizational_management over the competing primary. Case and workflow management routes records through admissible paths and can resume a suspended or failed process from preserved state; organizational process design generalizes that logic beyond software. The cited IBM: Resuming workflows provides direct evidence for that defining form. Alternates are retained only where they contributed an independent formative tradition, while domain_reach=multi_domain records later transfer separately from historical origin.
Review outcome: Researched adjudication after independent review; medium confidence.
Sources consulted:
References¶
[1] Avižienis, A., Laprie, J.-C., Randell, B., & Landwehr, C. E. "Basic Concepts and Taxonomy of Dependable and Secure Computing". IEEE Transactions on Dependable and Secure Computing 1(1), 11–33 (2004). Defines partial service failure as a degraded mode that still provides a subset of needed services. registry ↩