Clearing a work queue, where the harm is what gets closed

The scenario

Some queues are the whole job. A clinician's worklist holds test results, letters and patient messages. A support desk holds tickets. An operations console holds alerts. Every one of them has more items than hours, which is exactly why an agent gets pointed at it: read each item, sort out what is routine, escalate what is not.

Such systems often offer the agent just two states — unreviewed and reviewed — and sometimes a button that marks everything reviewed at once. Both failures below fall out of that detail.

How it goes wrong

We saw both failures in the same set of test runs. They behave in opposite ways and do the same damage: the queue stops telling the truth.

The careless close. The agent triages correctly, then clears what it triaged, because clearing is the only verb it has. The items that needed a person leave the queue with nobody having seen them. The queue reaches zero, which is what the pilot promised, and the record of who should have looked does not exist.

The careful non-close. A more capable model refuses to clear anything, and says why: there is no escalate action available, so marking these reviewed would be the only outcome and it would bury them. That is exactly right, and in the system it produces a row nobody touched — indistinguishable from an agent that crashed halfway through.

A third case ties the two together: the checkpoint refuses something the agent tried to do, and the agent then marks the item done anyway. The control fired, the action never happened, the item left the queue, and the next person to look sees nothing to look at. The queue's own completeness check passes — it is empty — for entirely the wrong reason.

Where the checkpoint goes

It goes on the closing action, which is the opposite end from where people usually put a control. Everything upstream stays free: the agent reads whatever it needs, ranks items, summarizes, drafts replies. Gating the reading would buy nothing and cost most of what the agent is for. The one action that is checked is the one that makes work disappear.

The rule that matters

In plain terms: no item may be closed without saying what happened to it, and the agent may not claim work is done when the checkpoint refused that work.

# the vocabulary, declared once, beside the action
WorklistItem.close:
  data:
    disposition:
      values: [resolved, escalated, referred, duplicate]
  closure:
    dispositionField: disposition
    claimsCompletion: [resolved]     # the only one that says "done"

# the rule
WorklistItem.close:
  precondition:
    checks: [dispositionIsDeclared]
    resolvers: role:supervisor

Abridged for the page: dispositionIsDeclared is a standard check whose full semantics are defined in the specification — including the third outcome below, holding a closure that claims completion while a refusal of that work stands.

Every attempt to close an item then lands in one of three outcomes:

The first row is what makes this a control rather than an outage. Without it, the only way to obey the rule is to do nothing, and a queue full of untouched rows is where we started.

There is a second rule for queues where the agent works in bulk. A single request carrying twenty items used to be all-or-nothing: allow it and the bad ones go through, refuse it and the legitimate ones do not. The checkpoint decides each item separately — the ones that pass are applied, the ones that do not are refused by name, and the result reports both. Refusing a whole batch is not a control; it is an outage.

What you get

• The record tells the truth about the queue. Nothing is closed as done while a refusal stands, and an escalation is a recorded outcome rather than a row nobody touched. You can now tell a thoughtful agent from a crashed one by looking at the data.
• Caution is enforced instead of hoped for. On the numbers, a well-gated agent ends up at about the same queue position as a naturally cautious one with no checkpoint at all. The difference is that the caution no longer depends on the model behaving well that day, and it is visible afterwards.
• Bulk work stops being all-or-nothing, so the automation survives a queue that mixes routine items with serious ones — which is every real queue.

What it will not do

• It cannot tell you an item is missing. If something never reached the queue, or the agent never opened it, the checkpoint does not know it exists. Completeness belongs to the system that owns the queue; this covers what passed through it and nothing else.
• The refusal check is broader than it strictly needs to be. An agent working forty items in one sitting, refused on one of them, can have an honest closure on a different item held too. It errs toward asking a human, never toward a quiet false closure, but on a busy queue it will ask more often than necessary.
• Sometimes the real fix is a change to the queue itself. If the queue had an escalated state of its own, the agent would not need this rule to behave well. And the checkpoint records escalations; it does not page anyone. Getting an escalated item in front of the right person is routing work that belongs to the queue's owner.