Skip to main content

The Honest Queue

A full redesign of the SlopU Office of Everything's front counter, defended against normal demand, congestion, uncertainty, failure and cancellation.

Due: 14 May 2027 · Weight: 50%

Purpose

The Honest Queue is the semester’s redesign. It asks you to specify, in enough detail that someone else could implement it, how the Office of Everything’s front counter should actually work — and to defend every decision in that specification against the case built up since week 1.

The task

Write a redesign of the Office of Everything’s front counter that specifies, at minimum:

For at least one of these decisions, state the alternative you rejected and your reason for rejecting it.

What you submit

The defence is written; lab questioning is formative practice, not an additional oral assessment. Submit a single written specification covering all six points above, organised so a reader can find each requirement addressed without hunting for it.

Support the ordering decision with a comparison of the same two rules on Normal Day and System Shock in the Queue Policy Lab, or separately declared and calculated equivalent cases if you propose a custom rule. Identify who benefits, who waits longer, and what the model does not test. The Lab has no cancellation, sign-comprehension or dispenser-failure model; its results cannot verify those parts of your redesign.

Scope boundaries

This is a specification, not a working system — you are not required to build a simulator, a scheduler, or a functioning wait-time estimator. Every claim about the Office of Everything’s behaviour must be grounded in the synthetic case material already established in earlier weeks or a plainly stated new assumption; do not introduce real-world statistics, studies or named laws to support the design.

Relationship to other work

The Honest Queue is where the semester’s separate threads — measurement (weeks 1–3), policy choice (weeks 4–6, rehearsed formally in the Policy Trial), and honest communication under uncertainty and failure (weeks 7–11) — have to work together in one specification rather than being demonstrated one at a time. Nothing here introduces a new concept; it asks you to use all of the earlier ones at once, correctly, and to say so when they pull against each other.

Submission requirements

A submission must meet all of the requirements below. They define the common task; the marking model describes the quality of the response.

How it is marked

The redesign is judged as a whole against the requirements below, not as a checklist scored piece by piece. A strong submission makes specific, defensible decisions on each requirement and is honest about what those decisions cost; a submission that is thorough on some requirements and silent on others is judged on its weakest point, since an Office of Everything that only works under normal demand is not the one this course asked for.