SUMMARY: A queue discipline is the rule used to select the next request for service. Audit it with synthetic records or a permitted read-only sample before attempting any live exercise. The aim is to explain observable ordering, not to flood a service or manufacture urgent cases.
1. State the Promise
Write down the service’s intended ordering rule, including exceptions. Identify the event that starts its clock, who can change priority, and whether any guarantee exists for older requests. If the rule is undocumented, record that uncertainty rather than inferring fairness from the interface.
2. Build a Small Case Set
In a tabletop review, create four fictional requests: A arrives first and needs lengthy work; B arrives next and is simple; C arrives later with an accepted urgent classification; D arrives with missing information. Give each a receipt timestamp, admission timestamp if applicable, service class, estimated effort, and current owner.
Agree on expected behavior before inspecting results. Under strict arrival order, B does not overtake admitted A merely because it is shorter. Under an urgency rule, C may move ahead if the declared condition is met. D may wait outside the service queue, but its intake record still needs a visible state and a responsible owner.
3. Change One Condition at a Time
Resolve D’s missing information. Transfer A to another team. Repeat B’s submission with the same reference. Age A beyond the declared review threshold. For each transition, ask whether the original receipt remains available and whether a priority change has a recorded reason.
A system may intentionally use different clocks for different obligations. The test is that it preserves their meaning instead of silently replacing one with another. The Invisible Queue explains why receipt and admission must remain distinguishable.
4. Keep an Evidence Row
- Case: a synthetic reference, never a public personal identifier.
- Before: state, owner, clock values, and service class.
- Transition: the event being tested and its timestamp.
- Expected: the relevant ordering or aging rule.
- Observed: what changed, what stayed, and what could not be verified.
- Disposition: explanation accepted, defect assigned, or uncertainty retained.
5. Close the Review, Not the Evidence
Investigate discrepancies before labeling them defects: capacity may be reserved, work may already be in progress, or an exception may be legitimate. Require those explanations to be traceable. Review long-waiting cases as well as completed ones so an apparently successful sample does not exclude the requests that never got served.
Assign a corrective owner and retest only the affected transition. Use the Burden Ledger if retries force participants to repeat work, and the Digital Systems Accountability guide when the queue problem also blocks explanation or correction.
Acceptance rule: every tested departure from the published order has an explicit explanation, and no transition silently destroys the evidence of waiting. The policy choices behind that order are examined in Priority as Policy.
Place this queue test within the broader decision accountability workflow, which also checks evidence, response access, and participant effort.