Release a queue comparison only after validating observation entry, status timing, common-horizon support and the action-unit interpretation.
Project: audit specialist-queue resolution comparisons
Freeze two cohorts and one question
Create a case-created cohort for service-wide resolution and a separate specialist-entry cohort for the conditional queue view. Keep created time, specialist-entry time, resolution or cancellation time, extraction cutoff, queue assignment and customer ID. State whether the decision is about all created cases, cases that reached a specialist, or cases still open at a day-four landmark. These are different populations. Delayed entry cannot silently turn one into another.
Verify the event accounting
Reproduce the delayed-entry teaching ledger with risk counts two at day two, four at day five and two at day seven. Then reconcile the production extract: one case per ID, entry earlier than exit, no terminal event after a case has left observation, and a documented rule for same-day events and censoring. Preserve cancellations as their own cause when they prevent ordinary resolution. Cause-specific incidence belongs beside any open-time curve.
Show uncertainty with denominator support
For each queue, print the unresolved share and at-risk count at the prespecified business horizon, plus a pointwise interval where its assumptions hold. A case-created queue introduced too recently may have too little mature follow-up; withhold the cross-queue figure rather than extend a flat tail. The interval does not validate independent censoring. The uncertainty lesson separates statistical spread from observation bias.
Compare bounded open time carefully
Use a shared six-day horizon only if both queues support it. A test ledger without early censors gives 29/6 case-days for queue A and four for queue B, so the descriptive A-minus-B difference is 5/6 case-day. In the real ledger, early censors require survival-curve integration rather than capped averaging. Record a customer-level resampling plan if one customer can create repeated cases. The contrast lesson identifies the needed assumptions.
Reject a misleading escalation story
Do not label cases eventually escalated as escalated at creation. If escalation status is part of a secondary comparison, define a day-four landmark, retain only cases open at that instant, and use status already known by then. Explain that the resulting estimate is conditional and observational. The final packet contains cohort definitions, input checks, event tables, cause-specific outcomes, horizon support, uncertainty method, time-varying status policy and a clear release or withhold decision. Landmark analysis specifies the boundary.
Implementation
def audit_queue_records(case_records, horizon_days):
if horizon_days <= 0:
raise ValueError("invalid horizon")
if len({case_id for case_id, _, _, _, _ in case_records}) != len(case_records):
raise ValueError("duplicate case ID")
queue_counts = {}
for case_id, queue, entry_day, exit_day, outcome in case_records:
if entry_day < 0 or exit_day <= entry_day:
raise ValueError("invalid observation interval")
if outcome not in {"resolved", "cancelled", "censored"}:
raise ValueError("unmapped terminal status")
counts = queue_counts.setdefault(queue, {"cases": 0, "at_risk_at_horizon": 0})
counts["cases"] += 1
if entry_day < horizon_days <= exit_day:
counts["at_risk_at_horizon"] += 1
if len(queue_counts) < 2:
raise ValueError("comparison needs at least two queues")
return queue_counts
ledger = [("Q51", "north", 0, 2, "resolved"),
("Q52", "north", 0, 8, "censored"),
("Q53", "south", 0, 5, "resolved"),
("Q54", "south", 0, 8, "cancelled")]
readiness = audit_queue_records(ledger, 6)
assert readiness["north"]["cases"] == 2
assert readiness["south"]["at_risk_at_horizon"] == 1Performance and operating cost
Validation of N case records is O(N) expected time and O(G) space for G queues. Estimating each curve adds sorting; uncertainty resampling adds repeated case-level passes. A release should block on absent follow-up or inconsistent status mapping even when all code completes.
Common Mistakes
- Do not mix a case-created population with a specialist-entry population in one denominator.
- Do not release a queue difference solely because the point estimates separate.
- Do not interpret eventual escalation as a baseline attribute.
Read next
- Delayed entry and left-truncated risk sets
- Survival-curve uncertainty and thin-tail support
- Landmark analysis and immortal-time traps
- Compare queues by restricted mean open time
Continue the workflow: Project: review a support-resolution survival model.
Continue the workflow: Project: validate a time-updated resolution model.
Continue the workflow: Project: compare specialist queues with censored resolution times.
