Skip to content

Triage Protocol Update

Intake protocol — instantiates Response Repertoire Expansion

Revises the front-door rules that classify and prioritize incoming cases, so a newly-recognized case class is sorted, ranked, and sent to the pathway that can actually handle it — instead of falling through.

A Triage Protocol Update revises the intake rules that sort and prioritize arriving demand, adding a category and routing rule for a case class the old triage did not recognize. Its distinctive position is the front door: it operates on the whole stream of incoming cases — classifying and ranking them and directing each to the right pathway — as opposed to selecting a response for a case already in hand. Its job is that no case in the newly-recognized class is silently mis-sorted, deprioritized, or dropped before any response can reach it.

Example

An IT service desk starts seeing a new case class — reports that are actually early signs of a security compromise — buried in ordinary "can't log in" tickets and handled at low priority, sometimes for days. The triage protocol is updated: intake adds a category with tell-tale signals (impossible-travel logins, MFA-fatigue reports), a priority bump that routes these straight to the security queue, a boundary rule that escalates any ticket with active data-exfiltration signs immediately, bypassing the normal SLA, and a compatibility check that the routing tags map onto the security team's ticketing fields. A case class that used to drown in the general queue is now caught, ranked, and routed at the door.

How it works

The mechanism re-partitions incoming demand. It adds a recognized class to the intake taxonomy, sets where the boundary of "normal handling" lies and when a case must escalate or route elsewhere, and ensures the new routing is compatible with the downstream systems and queues that must receive it. It governs sorting and priority — not the response itself, and not the selection made once a responder is already engaged.

Tuning parameters

  • Category resolution — how finely intake distinguishes classes. Finer resolution catches more but slows triage and risks mis-classification.
  • Priority weighting — how aggressively the new class is bumped. Over-prioritizing starves other work; under-prioritizing recreates the original drop.
  • Screening sensitivity — how eagerly the classifier flags the new class. High sensitivity catches near-misses but floods the target pathway with false positives.
  • Escalation threshold — how severe a case must be before it bypasses the normal flow entirely.

When it helps, and when it misleads

Its strength is that it ensures a newly-added response is actually reached, by catching and ranking its cases at intake before they are mis-sorted. Its failure mode lives on the over- versus under-triage trade-off: set the screen too loose and the target pathway drowns in false positives — and staff learn to ignore the flag — while too tight a screen lets the very cases it was built for slip through.[1] The classic misuse is adding a high-priority category for a politically-visible case class that jumps the queue regardless of real urgency. The discipline is to tune sensitivity against measured over- and under-triage rates and to revisit the protocol as the case mix shifts.

How it implements the components

  • unhandled_case_class_map — adds the newly-recognized case class to the intake taxonomy so it is sorted rather than buried.
  • boundary_and_escalation_rule — sets where normal handling ends and when a case must escalate or route elsewhere.
  • compatibility_constraint — ensures the new routing tags and priorities fit the downstream queues and systems that receive them.

It does not specify or resource the pathway a case is routed to — that is New Service Tier and the authoring mechanisms — and it does not select the specific response once a case is in a responder's hands; that is Decision Tree Update.

  • Instantiates: Response Repertoire Expansion — it makes sure a newly-added response's cases actually arrive at it, sorted and ranked.
  • Consumes: New Service Tier and other pathways receive the cases this protocol routes.
  • Sibling mechanisms: Decision Tree Update · New Service Tier · Cross-Training Program · Exception Handling Playbook · After-Action Repertoire Review · Competency Matrix Update · Controlled Pilot · Job Aid Checklist · Runbook Library Update · Scenario Drill · Tool Capability Addition

References

[1] In medical triage, the twin errors are overtriage (sending low-acuity cases to scarce high-acuity resources) and undertriage (missing a case that needed them). A good protocol is explicit about which error it is more willing to make, because it cannot minimize both at once. ↩