Support is the use case the catalog reaches for Jev most often, and for good reason: it is a long chain of small judgments over text, and almost every step is a bounded choice. It is also where the failure modes are most visible, because a wrong decision reaches a customer. The use-case map and the intent-routing pattern are the canonical references; this is the shape of the whole pipeline.
Step one: triage, not resolution
The first decision is not "how do we fix this" but "what is this and how urgent." Those are separate, atomic questions. Ask a Choice for the category and a Noul for whether it needs a same-day response, against the same message state. The intake router is the clinical version of this exact split; the support case is identical.
Keep them separate because the thresholds differ. A category answer needs no gate; an urgency flag routes straight to a queue, so its threshold carries the cost of a missed escalation.
Step two: route with confidence, not just with a label
Routing is where the SDE cascade earns its place. The cascade is a sequence of decisions with an escalation gate: a fast decision handles the easy majority, and anything below a confidence floor moves to a slower, more careful step or to a person. The 0.7 escalation gate the cookbook uses is a starting point, not a constant.
This is the pattern that keeps cost proportional to difficulty. A clear billing question is answered by the first hop; an ambiguous, angry, multi-issue message falls through to a human, and only where it should.
Step three: decompose the hard tickets
A message that asks three things is not one classification. The hierarchical classification cookbook shows the general move: classify one level at a time rather than passing a whole taxonomy at once. In support that means classifying the primary issue, then asking about the secondary issue only if the primary is not "resolved." Chaining Choices beats a 200-option rubric, which hits the option limit and blurs easily confused categories.
Step four: draft or hand off, decided in code
The judgment stops at the label; the action is code. Whether a routed ticket gets an auto-reply, a macro suggestion, or a human owner is a policy decision, and it should branch on the category and the confidence rather than on anything the model writes. This is the fail-closed discipline at the support boundary: an uncertain answer goes to a person, never to a customer, unless you have decided otherwise.
What support teams get wrong
- One giant rubric. A single "what is this ticket" Choice with dozens of options scores worse than a short first-pass Choice followed by a second.
- Blending urgency and category. They have different costs of error and belong in different questions.
- Trusting a confident wrong answer. The threshold article is the antidote; a high confidence is not a correctness guarantee.
- Logging only the label. Keep the distribution and the model version, so a routing change can be explained later.
Triage, gate, decompose, then act in code. Support is the clearest demonstration that a decision pipeline is a set of small, separately tunable judgments rather than one big one.