Order items by how cheap they are to find

What it is

Checklist items are ordered by discovery cost: first the items you can see on open, with no fabricated data and no account switch; then the items that need a special environment. The order serves defects found per hour, not “which item feels more important”. Importance governs fix priority, a different ledger.

Inspection time is capped. Items at the tail are dropped. If the head is all dual-account, device, cross-timezone work, cheap and common defects — empty copy, disabled that looks clickable — never get a turn.

Why it happens

Search under a time cap should sweep low-cost regions first. Opening the default page, reading empty, checking that the primary button is still the primary action, checking that the error sits beside the field, costs one click. Fabricating a failed payment, requesting a restricted account, installing a client on an old OS, costs most of a session. High-cost items at the front spend the budget on setup; low-cost items, sitting at the tail, are cut — and those items usually have the larger defect base, because every session hits them.

Discovery cost and harm are not one axis. A high-harm, expensive-to-find item should not jump the queue as a display of seriousness; seriousness is its own window or an automated check, not license to crowd out cheap items. Ordering only answers “what does this hour look at first”, not “what must be fixed”. Bind the axes and the list sorts by anxiety, which tracks the pain of preparing an environment, not how often a user meets the miss.

Where it stops holding

On a last pre-ship pass, a high-harm path this train just touched may move forward — “just changed” has already paid the discovery cost: environment and data are up. A newcomer’s first run makes cheap items costly to learn; keep the steady-state order and spend one shadowed session on learning, rather than rewriting the list hard-to-easy. Screen-reader and keyboard paths look expensive, but they are a statutory slot on every release; they occupy a second queue, not a fight with cheap visual items for the same head.

Applying it

• Tag each item with discovery cost: visible on open / needs fabricated data / needs another account or device. Print the live list in that ascending order.
• Spend the first twenty minutes only on “visible on open”; those minutes may not be used to install an environment.
• Give high-harm expensive items their own window or a script; do not insert them into the first twenty minutes as a show of seriousness.
• How to check: time one inspection. If the first twenty minutes are mostly waiting for an account or a package, the order failed. Compare historical defects: if empty and disabled issues dominate and sit in the list’s last third, while the first third is all environment, reorder by discovery cost and compare defects found in the same elapsed time.

Related

• Same group: R2.03.1 Checklists must cover states and edge cases · R2.03.2 Automation can only police the numeric layer · R2.03.3 Semantic consistency requires human judgment · R2.03.4 Every checklist item must be answerable yes or no · R2.03.6 Grow the list from defect reviews, not from taste
• Adjacent: R1.18 Adoption and compliance metrics · R2.12 Design–engineering cadence
• Search terms: discovery cost · inspection order · cheap to find · checklist sequencing