B.4.1:13 - Worked Route Sets
B.4.1:13.1 - Multi-route operator case
An operator alert note records a service-latency rise after a configuration change and a response-time clause whose applicability to this service is unresolved. The operator may admissibly publish a route set containing:
ActionInvitationRoute,ProblemAbductionRoute,- and
RequirementCommitmentRoute.
Keep the plurality explicit until a selected route is justified. The missing discriminator for RequirementCommitmentRoute is whether the clause covers this service and incident window. If it does, use A.2.8 for the question of an actual duty; the latency cue can still support intervention and explanatory inquiry.
B.4.1:13.2 - Inquiry case
A conceptual mismatch may route simultaneously toward:
- explanatory inquiry,
- probe design,
- and later lexical repair.
This is admissible only if the route rationale makes the plurality explicit rather than hiding it under vague prose.
B.4.1:13.3 - Invalid direct jump
It is invalid to treat a routed cue set as if it were already a hypothesis, a gate, or a work plan. The route-bearing publication form records candidate continuations; the applicable subject pattern governs the downstream result.
B.4.1:13.4 - Specialization-route and nonhuman-utility split
A routed cue set for a new task family may admissibly keep ProblemAbductionRoute, TaskFamilySpecializationRoute, and NonHumanUtilityRoute live together. The point is to preserve the declared task family, utility target, current budget window, missing discriminator, and possible corridor-entry load without laundering those routes into a premature prompt, selector, or policy choice.