Every factory has a gate nobody remembers installing. An extra inspection step that appears redundant, a signature box on a form that seems ceremonial, or a quarantine hold adding twelve hours to lead time for reasons long forgotten. These are the fences of quality — controls existing in a system without anyone able to articulate their exact purpose.
These controls are artifacts of lessons learned, crises survived, and knowledge once urgent enough to codify into procedure. They accumulate over decades, slowly fading into bureaucratic background noise. And they are inevitably the first things targeted when an organisation decides to streamline.
In 1929, G.K. Chesterton observed that a reformer who cannot see the use of a fence has no right to remove it. In quality management, this is a recurring catastrophe. The inability to explain why a control exists is not evidence that it is unnecessary; it is evidence that you do not understand your own process well enough to modify it safely.
The anatomy of an unexplained control
Walk into any manufacturing facility with over ten years of operating history and you will find processes that have outlived their institutional memory. An incoming material check added after a supplier shipped nonconforming resin in 2011, though the supplier was replaced years ago. A dual-signature requirement on nonconformance dispositions instituted after a reclassification scandal that nobody discusses.
Some of these fences are genuinely obsolete. The question is whether you can tell the difference between the obsolete controls and the critical ones before you remove them. The dangerous fences are not the ones with obvious purposes — they are the ones whose purpose has become invisible precisely because they work so well.
Consider the parameter range that prevents a failure mode listed as 'remote' in your PFMEA. It hasn't occurred in so long that the engineering team assumes the risk has been engineered out. In reality, the control prevents the problem so effectively that the problem disappears from organisational consciousness. The control becomes a victim of its own success.
Eventually, someone with a spreadsheet showing cycle time savings asks the fatal question: why are we still doing this? I have audited plants where well-meaning process engineers dismantled critical safeguards simply because the historical failure data had been archived. They mistook an absence of recent defects for permanent risk elimination.
The streamlining trap and invisible prevention
The pressure to remove unexplained controls comes from the best of intentions. Lean initiatives, cycle time reduction, and digital transformation all rely on eliminating non-value-added steps. Most of the time, the person proposing the removal is correct. A rigorous review of any mature IATF 16949 or AS9100 system will reveal controls that can be safely eliminated.
But the distinction between removable and essential fences is not found in whether the current team can explain them. It is found in whether you have done the work to reconstruct the original reasoning. Organisations fail when they confuse two fundamentally different questions during a kaizen event.
The false equivalence in control elimination
What teams ask
- Can anyone explain why this exists?
- Is it slowing down our cycle time?
- Is it documented in the current control plan?
- Do competitors perform this check?
What teams should ask
- Has the originating failure mode been eliminated?
- What original CAPA or 8D drove this requirement?
- Has the tooling, material, or supplier changed since?
- What is our detection capability if we remove this now?
The first question is easy to answer. You ask around, nobody knows, and you conclude the control is unnecessary. The second question requires investigation — digging into change histories, reviewing old 8D records, interviewing retired engineers, and tracing the control back to its origin. It is slower, harder, and it is the only question that matters.
The deepest problem with Chesterton's Fence is that the most critical controls are the hardest to see. An automotive supplier I worked with had an additional dimensional check on a machined surface, adding ninety seconds to every setup. Operators complained. The Cpk was 1.67. The check was removed during a kaizen event to celebrate cycle time improvements.
The asymmetry of risk
Fourteen months after that dimensional check was removed, a field failure occurred. A safety-critical dimension was drifting, and the standard SPC chart hadn't flagged it. The shift was within control limits but crossed a functional boundary that the original engineer had known about but never documented. The extra check was the only control detecting that slow drift early enough to correct it.
The Cpk of 1.67 was a historical artefact; the process had shifted six months earlier due to an unrecorded tooling change. The additional dimensional check was not redundant. It was the only control accounting for a failure mode known to a single engineer who had retired three years prior and was never debriefed. The field failure cost $4.2 million. The ninety seconds saved per setup was worth roughly $18,000 annually.
The math of Chesterton's Fence is asymmetrical. The cost of keeping an unnecessary fence is typically small and ongoing, measured in seconds and frustration. The cost of removing a necessary one is catastrophic and delayed, often arriving over a year later when the process conditions finally align to trigger the dormant failure mode.
This asymmetry must inform the burden of proof. When evaluating a control for removal, the burden falls entirely on the team proposing the change. They must prove the control is obsolete; the control does not have to prove it is necessary. The default position is preservation until proven otherwise.
A framework for safe dismantling
Chesterton did not argue that fences should never be removed. He argued that the threshold for removal should be understanding, not ignorance. Applied to quality systems, this creates a practical framework that treats every legacy control as a hypothesis to be tested, not a problem to be solved.
The control evaluation sequence
- 011. Reconstruct the originSearch CAPA databases, 8D records, engineering change orders, and customer complaint archives.
- 022. Assess current relevanceDetermine if the originating condition — a specific supplier, machine, or customer requirement — still exists.
- 033. Verify through dataUse process capability and historical performance data to evaluate detection capability if the control is removed.
- 044. Remove provisionallySuspend rather than delete. Monitor output closely over full production cycles to capture seasonal variation.
- 055. Document the decisionRecord why the control was originally installed, why it was removed, and what evidence supported the removal.
The provisional removal step is where most teams fail. They delete the control from the procedure and move on. A proper trial requires running the process without the control but increasing inspection intensity downstream. If problems emerge over production cycles sufficient to capture material and environmental variation, the control is reinstated. If no issues surface over several months, the removal is formalised.
Documentation is the final and most critical step. When you remove a control, you must record why it was originally installed and what evidence supported the decision to remove it. This protects future teams from relearning the same lesson and builds the institutional memory that prevents the next iteration of the problem.
Customer-driven and regulatory fences
Some controls exist because of a customer's experiences, not your own. A requirement may be buried in a quality agreement signed a decade ago and renewed automatically since. The customer may have imposed the control after a catastrophic failure at their facility — an incident your company was never involved in but that shaped their supplier requirements permanently.
The cost of keeping an unnecessary fence is small and ongoing. The cost of removing a necessary one is catastrophic and delayed.
Removing a customer-imposed control without understanding its origin risks contract violation, a discovery that typically arrives as a major nonconformance during a customer audit or PPAP submission review. The correct approach is direct engagement: explain that you cannot trace the technical basis and ask whether the underlying concern persists. Some customers will support removal; others will insist the control remain. Either way, you have converted an unexplained fence into an understood one.
Regulatory fences are even more dangerous. A control added to satisfy an FDA observation, an EASA requirement, or an IATF 16949 finding may not be obviously regulatory in nature. It may look like an internal best practice. An improvement team can remove it without recognising the compliance exposure, and the consequences extend far beyond a quality department into legal liability.
Before removing any control, check its regulatory pedigree. If it was added in response to an audit finding or a customer-specific requirement linked to a regulatory framework, it stays until you can demonstrate full compliance without it. The age of the requirement is irrelevant; regulatory weight does not diminish with time.
Building institutional memory into the control plan
The long-term solution to Chesterton's Fence is not better removal procedures — it is better creation procedures. Organisations accumulate controls faster than they accumulate understanding of those controls. The person who adds a control understands its purpose. The person who inherits it three years later sees only the procedure.
This is a documentation failure, but not the kind most quality departments expect. The issue is not missing procedures; most ISO 9001 systems are over-documented. The issue is missing rationale. Procedures tell you what to do. Rationale tells you why. And the why is always the first thing lost to time, staff turnover, and system migrations.
The most resilient quality systems share a common structural trait: every control in the system has a documented reason for existing, linked to a specific risk it mitigates. When the risk can be demonstrated as resolved — the supplier replaced, the machine rebuilt, the customer lost — the control is removed with confidence. When the risk persists, the control remains regardless of whether anyone remembers the original incident.
This requires adding a single field to your control documentation: Purpose. Not the procedure's name, not its scope, but the specific failure mode, risk, or requirement it addresses. Assign ownership of that rationale to the person who adds the control. Make it a non-negotiable part of the engineering change process. With that single data point, Chesterton's Fence becomes a solvable engineering problem instead of a recurring operational disaster.