← All workshopsRead Can We Defend the Inspection Service Design?

Test the Design and Plan for Failure

Review Botie’s inspection service

Catch every labelled fault but overload the service

Botie's complete inspection proposal must meet a fault-miss limit and a queue budget. Its labelled pump fixture and arrival trace supply different evidence.

BOTIE

The busy shift inspects every known fault. Why should the full review still fail?
The inputs we are comparing

Fault labels in evaluation order

Both boundary checks pass

  1. 01
  2. 10
  3. 21
  4. 31

Busy shift fails capacity

  1. 01
  2. 10
  3. 21

Inspection decisions in evaluation order

Both boundary checks pass

  1. 01
  2. 10
  3. 20
  4. 31

Busy shift fails capacity

  1. 01
  2. 10
  3. 21

Maximum missed faults

Same in both cases

1

Request arrivals per interval

Both boundary checks pass

  1. 02
  2. 17
  3. 21

Busy shift fails capacity

  1. 02
  2. 19
  3. 21

Service capacities per interval

Same in both cases

  1. 04
  2. 14
  3. 24

Maximum permitted backlog

Same in both cases

3
Result for both boundary checks pass
1
Choose an explanation to test
Acceptable fault coverage still overloads the reviewers

This check uses the pieces from “Join the quality check and the workload check”.

BOTIE

Botie's inspection design must miss no more than one faulty machine and leave a peak queue of at most two jobs. Starting with an empty queue, add each slot's arrivals before applying that slot's capacity. Return 1 only if both the fault and queue checks pass.
Fault labels in evaluation order
  1. 01
  2. 10
  3. 21
  4. 31
  5. 40
Inspection decisions in evaluation order
  1. 01
  2. 10
  3. 20
  4. 31
  5. 41
Maximum missed faults
1
Request arrivals per interval
  1. 01
  2. 16
  3. 22
Service capacities per interval
  1. 03
  2. 13
  3. 23
Maximum permitted backlog
2

Use a number, text, or an array matching the requested result. For a matrix, put each row in brackets. Saving your prediction runs your current construction on these inputs and checks the earlier examples too.

Build a construction in the workspace above first. This case will test those pieces.

Which claims still need a field trial after both fixture checks pass: useful inspections, timely review, representative labels, or reliable input handling? Explain the evidence each claim needs.

Keep requirements, measured misses, peak backlog, model and data versions, assumptions, and unresolved checks in the design report. A fixture pass verifies its stated arithmetic; intended-use validation still needs real operational evidence.

This verifies two toy requirements. Field usefulness, inspection capacity, label coverage, memory, response deadlines, and fallback behaviour still need their own evidence.

Work through the Python challenges →
← What Should Happen When the Model Cannot Help?