Unsupported Case Triage Workflow¶

Case-routing workflow — instantiates Domain–Codomain Delimitation

Sorts the cases that fall outside the boundary — rejecting the clearly invalid, referring the elsewhere-owned, escalating the high-risk, and giving contested cases an appeal — so out-of-scope never means silently dropped.

An Unsupported Case Triage Workflow governs what happens after a case is judged out of domain. A gate or a set of criteria makes the in/out call; this workflow does the harder, more human job of routing the outs — because "out of scope" is not one thing. It distinguishes the clearly invalid (reject) from the elsewhere-owned (refer) from the high-risk (escalate) from the genuinely contested (send to appeal or review), and gives each a defined destination. Its distinguishing quality is that it treats the unsupported region as structured, not as a single reject bucket: it is the mechanism that ensures a case the system won't handle still ends up somewhere sensible, so falling outside the boundary is never the same as vanishing.

Example¶

A content platform's automated classifier flags reports it can't confidently resolve — the cases outside the "clearly allowed / clearly disallowed" domain. The Unsupported Case Triage Workflow sorts them rather than dumping them. A report that is plainly spam-bait is rejected with a standard response. A report that's really a copyright dispute is referred to the dedicated IP process — a different owner. A case with credible signals of real-world harm is escalated immediately to a specialist queue with priority. And a case where a user insists their removed post was fine is routed to an appeal path where a human re-reviews it — the exception path that protects a contested, high-stakes case from being finalised by an automatic exclusion. Four out-of-domain cases, four different fates, none silently closed. The workflow has turned "the classifier can't handle this" into "here is exactly where this goes."

How it works¶

The workflow first classifies each unsupported case by why it's out — invalid, elsewhere-owned, high-risk, ambiguous, or contested — then applies a route per class: reject with explanation, refer to the right owner, escalate to a faster/specialist path, defer to a fallback, or open an appeal/review. The two design commitments that make it work are that every out-of-domain case has a defined destination (nothing dead-ends) and that high-stakes or disputed cases get a human exception path rather than an automatic no. It is the operational counterpart to the boundary: the boundary says "not here," the workflow says "then there."

Tuning parameters¶

Route granularity — how many distinct out-of-scope destinations exist (one reject bucket vs. reject/refer/escalate/appeal). Finer routing serves cases better but adds process to build and maintain.
Escalation threshold — how high-risk a case must be to jump to a priority path. A low bar protects against missed harm but floods the escalation queue; a high bar is efficient but risks under-escalating.
Appeal generosity — how readily contested cases get human re-review. Generous appeal protects against wrongful exclusion but is costly and gameable; stingy appeal is cheap but hardens automatic errors.
Referral accuracy — how well "elsewhere-owned" cases are matched to the right owner. Good matching genuinely offloads; bad matching just relays the case in a circle.

When it helps, and when it misleads¶

Its strength is that it makes the boundary humane and safe: legitimate-but-unsupported cases get referred instead of stonewalled, dangerous cases get escalated instead of buried in a queue, and contested cases get an appeal instead of a final automatic no. It is also where a system avoids the worst failure of a boundary — the silent drop, where an out-of-scope case simply disappears with no response and no owner.^[1] Its own failure modes are a triage that collapses every route into "rejected" (the boundary becomes a wall), an escalation path so easy to trigger it becomes noise, or an appeal path so generous it re-admits the very cases the boundary excluded — quietly dissolving the domain from the exception side. The discipline is to keep the routes genuinely distinct, to feed recurring out-of-scope patterns to Scope Change Review (a class of cases that keeps arriving may mean the boundary is drawn wrong), and to make sure appeal corrects errors without becoming a back door.

How it implements the components¶

unsupported_case_boundary — operates the distinction among invalid, ambiguous, high-risk, and elsewhere-owned cases, treating the unsupported region as structured rather than a single bucket.
safe_rejection_or_deferral_path — provides the defined destination (reject, refer, defer to fallback) for each out-of-domain case, so none dead-ends.
exception_review_path — the appeal/escalation route that protects high-stakes and contested cases from being finalised by an automatic exclusion.

It routes cases the boundary has already excluded; it does not draw the input domain (Eligibility Criteria, Clinical Indication Criteria), make the admit/refuse call at the door (Input Validation Gate), or decide whether the boundary itself should move (Scope Change Review).

Instantiates: Domain–Codomain Delimitation — the workflow is the operational handling of everything the boundary excludes.
Consumes: Input Validation Gate and Clinical Indication Criteria hand it the cases they judge out of domain.
Sibling mechanisms: Input Validation Gate · Scope Change Review · Service Scope Statement · Eligibility Criteria · Clinical Indication Criteria · Output Validation · Type Signature · Output Schema · Contract Test Suite · Model Applicability Card

References¶

[1] The silent drop — an out-of-scope case that is discarded with no response, no owner, and no record. It is the failure mode a triage workflow exists to prevent: an unhandled case should always be visibly rejected, referred, escalated, or deferred, never simply gone. ↩