Manufacturing Defect and Quality System Failure

A manufacturing defect is, by definition, a deviation from the manufacturer's own specification. The engineer's task is to show two things in sequence. First, what was the specification? Second, how did this unit depart from it?

1. Establish the design specification
   Obtain engineering drawings, material specifications, assembly procedures, and tolerance tables through discovery. These documents define what a conforming unit should be. Without them, the deviation cannot be measured.
2. Examine the unit at issue
   Measure, test, and if necessary destructively section the unit to determine its actual properties. Hardness tests, tensile tests, dimensional measurement, metallographic section, and SEM examination all serve to characterise what this unit actually was, as opposed to what the drawing said it should be.
3. Identify the departure
   State specifically how the unit deviates: the weld penetration was 40% of the required depth; the fastener torque was 12 N·m against the specification of 28 N·m; the material hardness was in the wrong range. Specific departures from specific requirements are what courts and juries can evaluate.
4. Link the departure to the failure
   Show causation: this departure, not some other cause, produced the failure mode that injured the plaintiff. The analysis must rule out user abuse, ordinary wear, or damage occurring after the incident to isolate the manufacturing defect as the operative cause.

Modern manufacturing processes generate substantial records. Heat treatment charts record the temperature profile and time of every batch. Welding logs capture current, voltage, and wire feed rate. CMM printouts record measured dimensions of each part. Torque wrench logs show the setting used on each assembly shift. These records are the factual backbone of any manufacturing defect investigation, and they are obtained through discovery or regulatory disclosure.

Statistical Process Control (SPC) records are particularly valuable. A manufacturer running SPC will have control charts plotting a key process variable over time. The rules for these charts, developed by Walter Shewhart and refined by W. Edwards Deming and the ISO 7870 series, identify signals that the process has moved outside its natural variation. If the control chart for the relevant process shows an out-of-control signal on or around the date the plaintiff's unit was manufactured, it is direct evidence that the process was not in specification at that time.

When records are missing or incomplete, courts have drawn adverse inferences in some jurisdictions. A manufacturer that is required by its own quality plan to retain SPC data for five years but cannot produce the records for the relevant period must explain why. The absence of records that should exist is itself a fact that the engineer should flag, not simply note as a limitation.

ISO 9001 is the world's most widely adopted quality management standard. Its current version (ISO 9001:2015) requires organisations to establish documented processes for design, production, measurement, customer complaint handling, corrective action, and management review. Certification by an accredited body confirms that an auditor found the system in place and operating; it does not guarantee that every product leaving the factory is defect-free.

In practice, the engineer reviews the quality management system documentation not to evaluate the system in the abstract but to identify what records should exist and then determine whether those records for the plaintiff's unit are present, complete, and consistent with the claimed specification compliance.

The Therac-25 was a computer-controlled linear accelerator built by Atomic Energy of Canada Limited (AECL) and introduced in 1982 for radiation therapy. It was designed to operate in two modes: a low-energy electron mode and a high-energy X-ray mode that required a metal target and a beam flattener to be positioned in the beam path. The Therac-25 differed from its predecessors (the Therac-6 and Therac-20) in a critical way: the hardware interlocks that physically prevented the high-energy beam from firing when the target was absent were removed, with software checks substituted instead.

Between June 1985 and January 1987, at least six patients in Canada and the United States received massive radiation overdoses from Therac-25 machines. Three died. The injuries, severe radiation burns, neurological damage, and death, resulted from the machine delivering its high-energy beam in electron mode, without the target assembly in place, at doses orders of magnitude above the therapeutic level. The patients experienced what felt like electric shocks and reported intense heat; many did not understand what had happened to them until days or weeks later when radiation damage became apparent.

The root cause, meticulously documented by Nancy Leveson and Clark Turner in a 1993 IEEE Computer case study, was a race condition in the software controlling the machine. The code included a variable called DATENT that tracked whether the collimator (the beam-shaping assembly) was in the correct position. When a radiotherapy technician entered a treatment mode and then edited it within a narrow time window, the multitasking operating system could set the beam output to high-energy mode before the DATENT flag was correctly updated. The safety check then passed on stale data, and the beam fired at high energy with the target absent.

The Therac-25 case is used in software engineering education worldwide because it illustrates several quality system failures simultaneously. The race condition itself was a software manufacturing defect in the sense that it was a deviation from correct behaviour that the design intent required. But surrounding it were deeper quality system failures: the reliance on a single software check in place of independent hardware interlocks; the absence of adequate testing for timing-dependent failure modes; an error-reporting system that displayed cryptic codes rather than actionable alarms; and an initial investigation process that attributed the first injuries to operator error rather than machine malfunction, delaying identification of the systemic problem.

Quality management records are technically dense and procedurally unfamiliar to non-engineers. The forensic engineer's report must translate them into a clear narrative: this is what the specification required; these are the records that should document compliance; here is the specific record that shows non-compliance; and here is how that non-compliance caused the failure that harmed the plaintiff.

• Specification: always anchor the analysis to the manufacturer's own documents. Arguing deviation from an external standard the manufacturer did not adopt is weaker than arguing deviation from the company's own drawing or quality plan.
• Process records: identify which records were required by the quality plan for this product and compare them against what was actually produced. Missing records, records with corrected values, or records outside specification tolerance are all significant.
• Inspection records: in-process and final inspection data show whether the non-conforming feature was checked. If it was checked and passed, either the inspection was performed incorrectly or the measurement equipment was out of calibration, both of which are additional quality system failures.
• Nonconformance reports: prior NCRs for the same feature or process show whether the manufacturer knew this was a recurring issue. A pattern of NCRs is evidence that the quality system identified the problem and the corrective action was ineffective.

For software, the equivalent of process control records are version control logs, test results, code review records, and defect tracking system entries. The question is whether the software release process included adequate testing for timing-dependent and concurrency failure modes, and whether the scope of testing was appropriate for a safety-critical application where the consequences of a software error were lethal.

In many cases the distinction between manufacturing and design defect is blurred at the outset of the investigation. The engineer should resist reaching a conclusion before examining both the failed unit and the specification. A useful initial diagnostic is to ask: if we built another unit exactly to the drawings and tested it under the same conditions, would it fail the same way?

In the Therac-25 context, the initial attribution of injuries to operator error is a classic example of prematurely ruling out a manufacturing (software quality) defect. The first technicians to encounter the malfunction reported the error to AECL and were told the machine passed all safety checks. It was only when multiple independent incidents occurred at different facilities that the pattern of a systemic quality failure became undeniable.