Decision Triage Queue¶
Workflow — instantiates Decision Load Management
A workflow that routes incoming decisions by urgency, stakes, reversibility, and owner.
A Decision Triage Queue sits at the intake point of a stream of unlike decisions and, for each arrival, answers a routing question: how urgent, how consequential, how reversible, and whose call is this? Its defining move is per-item classification-and-dispatch — every incoming decision is sized on a few axes the moment it lands and sent down the channel that fits it, so that a trivial reversible request and a high-stakes irreversible one never travel the same lane by default. It is not about gathering similar decisions to process together; it is about separating a mixed inflow so each item reaches the right treatment and the right owner. The queue's value is that it protects the expensive channels — senior judgment, deep review, escalation — from being clogged by items that a cheaper lane could have handled.
Example¶
An IT service desk receives a chaotic mix of change requests: password-policy tweaks, laptop reimaging, a request to open a firewall port, and a proposal to migrate a production database over a weekend — all arriving through the same ticket inbox and, until now, all worked in roughly the order received. Consequential changes waited behind trivial ones, and occasionally a genuinely risky change slipped through on a quiet afternoon with only a cursory glance.
The team installs a triage queue. Each incoming ticket is tagged at intake on four axes: urgency (is something broken now?), stakes (blast radius if it goes wrong), reversibility (can we roll it back?), and owner (whose domain?). A low-stakes reversible request routes straight to the front-line queue for same-day handling. A medium-stakes change routes to the owning team lead. Anything high-stakes or irreversible — the database migration — is flagged an exception and escalated to the change-advisory board rather than decided in the normal flow. The illustrative point is the routing table itself: a small, fast classification at intake that sends each unlike item to a proportionate channel, keeping the board's attention for the changes that truly need it. This is ITIL-style incident prioritization[n1] generalized to arbitrary decisions.
How it works¶
Triage runs at the moment of arrival, before any decision is worked. First a fast classification: score each item on a small fixed set of routing axes — typically urgency, stakes, reversibility, and domain — cheaply enough that the tagging itself does not become a bottleneck. Then a routing table maps combinations of those tags to destinations: a front-line auto-lane, a named owner, or the escalation path. The escalation lane is the load-bearing part — it exists specifically to pull unusual, high-stakes, or irreversible cases out of the low-load channels before they are handled as routine. Ownership is resolved by lookup, not negotiation, so items do not stall in "whose is this?" limbo. What triage deliberately does not do is merge like items into a shared session; each item is dispatched individually.
Tuning parameters¶
- Routing axes — which dimensions the queue sorts on. More axes (urgency, stakes, reversibility, owner, novelty) route more precisely but make intake tagging slower and more error-prone; fewer axes are fast but coarse.
- Escalation sensitivity — how readily an item is flagged an exception. Set it loose and the escalation lane clogs with items that did not need it; set it tight and a genuinely risky case slips through as routine.
- Owner-map resolution — how finely destinations are specified (a team vs. a named role). Precise ownership reduces ping-pong but demands an up-to-date map.
- Intake tagging effort — self-service tags vs. a triaging gatekeeper. A human triager is more accurate but is itself a load point; automated tags scale but misroute edge cases.
- Reversibility weighting — how much an irreversible flag alone forces escalation regardless of size, guarding cheap-but-permanent decisions.
When it helps, and when it misleads¶
Triage is the right tool when the inflow is heterogeneous — a mix of stakes, urgencies, and owners arriving through one channel — and the harm comes from treating them uniformly. By classifying at intake it keeps scarce judgment channels clear and ensures that irreversible or high-stakes cases get pulled up rather than waved through.
Its failure mode is misrouting at the front door: a fast intake tag is a shallow judgment, and an item mis-sized on arrival goes down the wrong lane — a subtly high-stakes change dispatched as routine, or a flood of over-cautious escalations that recreates the very bottleneck triage was meant to relieve. A queue can also become brittle when its owner-map goes stale and items route to people who have moved on. The guarding discipline is a deliberately generous reversibility/stakes trigger for escalation (when in doubt, route up), periodic sampling of auto-lane items to catch misroutes, and keeping the owner-map current. Escalation exists precisely so defaults and fast lanes do not become brittle procedural machinery.
How it implements the components¶
decision_stakes_classification— the intake tagging is a live stakes-and-reversibility classifier applied per item as it arrives.exception_and_escalation_path— the escalation lane routes unusual, high-stakes, or irreversible cases out of the low-load channels and up to appropriate review.choice_owner_map— the routing table resolves each item to its accountable owner by lookup, ending decision ping-pong.
It does not group like decisions into a planned processing window (batching_rule) or catalog what recurs (decision_inventory) — that gathering is the Decision Batching Workflow, its nearest twin. Triage separates a mixed inflow at intake; batching accumulates similar items to work together.
Related¶
- Instantiates: Decision Load Management — triage realizes the "classify and route each decision to an appropriate channel" intake logic.
- Sibling mechanisms: Decision Batching Workflow · Approval Threshold Matrix · Delegation Rulebook · Decision Calendar
Editorial Notes¶
Form Classification¶
Form family: Decision, Gate & Allocation
Rationale: Decision Triage Queue operates as a case-specific gate, selection, routing, prioritization, or resource disposition because it a workflow that routes incoming decisions by urgency, stakes, reversibility, and owner.
Independent corroboration: The frozen evidence defines Decision Triage Queue as 'A workflow that routes incoming decisions by urgency, stakes, reversibility, and owner', so its operative form is Decision, Gate & Allocation.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: Service and workflow management cohered intake queues that classify each item by impact, urgency, reversibility, and ownership before routing it to an appropriate handling lane.
Related originating lineages:
- Medicine & Healthcare — Clinical triage provides an older high-stakes lineage for rapidly separating mixed arrivals by urgency and required expertise.
Review resolution: Service and workflow management cohered intake queues that classify each item by impact, urgency, reversibility, and ownership before routing it to an appropriate handling lane.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] ITIL incident and change prioritization scores each item on impact and urgency to assign it a handling class and route. It is a widely used IT-service-management framework; a decision triage queue applies the same intake-and-route logic to decisions beyond IT. ↩