Case Study 2 — The Tolerance That Wasn't There: How One Missing Number Built a Thousand Bad Parts

A contrasting scenario—Deep Dive. Where Case Study 1 was a software-latency requirement, this one moves to hardware and the factory floor, where an ambiguous specification fails not once but on every unit until someone notices. It shows the cost gradient (§33.1) operating inside manufacturing, and the difference between a requirement, a work instruction, and an in-line check. Fictional but realistic.

The setup

A hardware company designed an enclosure for an outdoor sensor. A gasket sat between two halves of the housing to keep water out, and the design called for the two halves to be bolted together to compress the gasket to a sealing fit. The mechanical requirement in the specification read:

REQ-SEAL-007. The housing halves shall be fastened together tightly to compress the gasket and ensure a watertight seal.

The design passed review. The prototype, hand-assembled by the engineer who designed it, sealed perfectly—she'd tightened the bolts "until it felt right," which for her meant a consistent, moderate torque she applied without thinking. The product went to manufacturing. Within two months, the field failure reports started: a fraction of units were leaking, and a different fraction had cracked housings. Two opposite failures from one assembly step.

The diagnosis: a requirement masquerading as a specification

REQ-SEAL-007 reads like a real requirement. It uses SHALL. It names the goal (watertight seal). But run it through the chapter's test and it collapses:

• Testable? What does "fastened tightly" mean as a pass/fail criterion? There's no number. ❌
• Unambiguous? "Tightly" is the hardware twin of "fast"—it has a precise meaning in the designer's hands and no meaning on an assembly line where ten operators have ten different ideas of "tight." ❌
• What, not how, and the missing tolerance? The requirement specified the outcome (watertight) but the manufacturing step that achieves it needs a value with a tolerance, which existed nowhere.

Here's what happened on the floor. The work instruction inherited the vagueness: it said "tighten the four bolts until the housing is sealed." Each operator interpreted "until sealed" differently. The ones who under-torqued left the gasket insufficiently compressed—those units leaked. The ones who over-torqued (worried about leaks, erring toward "really tight") cracked the plastic housing or crushed the gasket past its sealing range—those units also leaked, or failed mechanically. The single under-specified value ("tightly") didn't fail once. It failed on a population of units, in two opposite directions, thousands of times, until the field data made the defect rate impossible to ignore. This is the cost gradient from §33.1 operating in real time: a defect that would have cost one sentence to fix in the requirements review instead cost a field-failure investigation, a production hold, and a batch of returns.

The fix: a requirement, a work instruction, and a check

The correction touched three documents, and untangling them shows why the chapter insists they're different genres for different readers.

1. The requirement got a verifiable target (the what). The engineers determined the gasket's correct compression and expressed it as something measurable:

REQ-SEAL-007 (revised). The assembled housing SHALL pass a water-ingress test at IP67 (per the project's environmental test plan, TC-ENV-003). The gasket compression SHALL be 15% ± 3% of its free thickness when the housing is fully assembled.

(Note: "fastened tightly" is replaced by a measurable compression target and a pass/fail ingress test. The requirement now states an outcome that can be verified, not a feel.)

2. The work instruction got a value, a tolerance, a pattern, and a sequence (the how, for the operator). The compression target became a torque the operator can reproduce identically on every unit:

Step 12 — Fasten housing (required: torque driver set to 1.2 N·m)

⚠️ Caution: Over-torquing cracks the housing and crushes the gasket past its sealing range. Do not exceed the set torque. The driver is preset—do not adjust it. 1. Place the housing top onto the base, aligning the registration marks. 2. Hand-start all four bolts (do not seat any bolt fully yet). 3. Torque the four bolts to 1.2 N·m ± 0.1 N·m in the cross sequence 1-3-2-4 (see Figure 12). 4. Verify: the housing seam is uniformly closed with no visible gap; the gasket is not extruding from the seam. If a gap is visible or the gasket extrudes, set the unit aside for inspection—do not pass it down the line.

3. An in-line check caught the failure at the station that caused it. The "Verify" sub-step and a periodic ingress spot-check moved the defect detection to the point of assembly, where a bad unit is cheap to catch—instead of letting it travel to a customer's roof, where it's expensive.

Why three documents, not one?

A reader new to engineering asks: why not just write one good paragraph? Because each document serves a different reader doing a different job, and conflating them is what caused the failure:

The original single sentence tried to be all three and was none. It stated a goal nobody could test, gave the operator no reproducible value, and built in no check. The lesson is the chapter's manufacturing point sharpened: on a production line, an ambiguous instruction doesn't risk one mistake—it guarantees a population of them, because the same gap is crossed on every unit. And the deeper lesson, the same as Case Study 1: "tighten it tightly" felt like a complete instruction for exactly the same reason "the system should be fast" felt like a complete requirement—the author could execute it perfectly from their own knowledge, so they never saw that the knowledge, not the words, was doing the work. The number had to be written down, with a tolerance, before a stranger could build the part right.

Back to: Chapter 33 · Case Study 1 · Exercises · Key Takeaways