CAP Governance

CAP is not a report. It is a verified path from failure to system improvement.

A case-based corrective-action framework that converts defect signals into containment, validated root-cause elimination, effectiveness evidence, and reusable manufacturing controls.

A problem is not closed when the slide is completed. It is closed when the cause is removed, effectiveness is proven, and the learning is embedded into the operating system.
SIGNAL
TO
SYSTEM
Detect
Eliminate
Verify
Learn
8 Governance stages from defect signal to verified closure
4 Action types that must not be mixed together
70.9% Contribution from the top two defect groups in the anonymized case
1 Closure rule: evidence plus effectiveness plus system update
01 · When to Open a CAP

Not every defect needs a CAP. Every systemic risk does.

CAP should be triggered by risk, recurrence, customer impact, or a measurable failure of process readiness—not by presentation preference.

01

Target Miss

Pilot or production quality performance exceeds the approved defect-rate threshold.

02

Critical Escape

Safety, compliance, critical function, or major customer requirements are at risk.

03

Repeat Defect

The same defect returns after a prior action, showing that the cause or control was not eliminated.

04

Control Failure

A Poka-Yoke, inspection control, reaction plan, or process gate fails to protect the output.

05

Capability Failure

The process cannot repeatedly hold the required performance window.

06

Customer Signal

Complaint, rejection, audit finding, or field feedback indicates a systemic issue.

02 · CAP Operating Flow

Eight steps move the team from symptom to verified system improvement.

Scroll through the cards. Each stage builds on the previous one, and the next stage should not begin until the current output is clear.

01

Detect the Signal

Start from a measurable deviation: defect rate, complaint, repeat issue, control failure, or readiness-gate miss.

Output: a factual trigger statement with target, actual, scope, and timing.
02

Contain the Risk

Protect current output before investigating the full cause. Stop, segregate, inspect, rework, or hold affected material.

Output: protected customer and clearly controlled suspect stock.
03

Define the Problem

Describe what failed, where, when, how much, and against which approved requirement. Avoid cause language at this stage.

Output: a problem statement that another engineer can verify.
04

Validate the Data and Prioritize

Reconcile the denominator, confirm defect quantities, remove category overlap, and use Pareto to focus on the vital few.

Output: one trusted data set for reporting and technical learning.
05

Prove the Root Cause

Use 5-Why, process comparison, trial evidence, capability data, or controlled testing. Do not stop at operator error.

Output: a cause that explains the defect and is supported by evidence.
06

Eliminate and Prevent

Separate immediate correction from corrective action and future prevention. Assign an owner, due date, acceptance criteria, and required evidence.

Output: actions that remove the cause rather than hide the symptom.
07

Verify Effectiveness

Confirm the action during pilot or production. Verify recurrence, capability, defect trend, and correct execution at the shopfloor.

Output: objective proof that the action works under real conditions.
08

Update the System and Close

Transfer the learning into PFMEA, Work Instructions, Control Plans, Poka-Yoke, training, NPI gates, and the lesson-learned library.

Output: verified closure that survives beyond the current project.
03 · Data Discipline

Management reporting and technical problem solving must use consistent, traceable logic.

Separate the Two Questions

A CAP can fail before root-cause analysis begins when the rate basis and Pareto basis are mixed together.

Management question What is the approved defect rate against the official report output basis?
Technical question Which defect categories contribute most of the actual NG quantity?
Rule: Use one approved denominator for reporting. Use actual NG quantity and Pareto percentage for technical prioritization.

Anonymized Pareto Example

In the reference case, the top two defect groups represented 70.9% of all nonconforming units.

Cause Group A
45.5%
Defect Group B
25.4%
Remaining
29.1%
Prioritizing the top two branches created the fastest path to meaningful defect reduction.
04 · Action Hierarchy

Containment, correction, corrective action, and preventive action are not the same.

01 · Protect

Containment

Protect the customer and current output while the real cause is still being investigated.

  • Hold suspect material
  • Segregate affected lots
  • Temporary inspection
02 · Restore

Correction

Repair, replace, or rework the specific nonconforming output already created.

  • Rework current units
  • Replace damaged part
  • Adjust affected output
03 · Eliminate

Corrective Action

Remove the verified root cause from the current process and project.

  • Validate process window
  • Lock parameters
  • Control force and position
04 · Standardize

Preventive Action

Convert the learning into a reusable rule that protects future projects and production.

  • Update PFMEA
  • Release Poka-Yoke
  • Strengthen NPI gate
  • Reuse lesson learned
05 · Case-Based Learning

One real pilot case can reveal two different system failures.

An anonymized pilot-production program exceeded its internal quality target.

Public-Safe Case

Pareto analysis identified two priority branches. One branch came from incomplete process readiness. The other came from uncontrolled manual variation. Both required different corrective and preventive actions.

Branch A

Process Readiness Failure

Output gap or joining variation
Process parameter window not stable
Equipment buy-off and parameter locking incomplete
Pilot proceeded before readiness gate was fully closed
Branch B

Manual Variation Failure

Cosmetic dent or impact damage
Assembly force and position varied
Manual process depended on operator judgement
Automated control was not ready for the early build
Current-Project Correction Stabilize the process, segregate affected output, and verify the corrected condition.
Corrective Action Validate and lock the process window, control force and position, and complete equipment buy-off.
Preventive Action Make readiness validation mandatory before pilot release and transfer the control into future-project standards.
06 · Verified Closure

“Implemented” is not the same as “effective.”

A CAP is closed only after implementation, objective verification, and system transfer are complete.

1
Owner and due date assigned
2
Containment completed
3
Root cause proven
4
Corrective action implemented
5
Evidence attached
6
Effectiveness verified
7
No recurrence confirmed
8
System documents updated
Closure rule: No evidence means not implemented. No effectiveness verification means not closed. A future-project action remains pending until it is validated.
07 · System Feedback

Every verified CAP must strengthen the engineering operating system.

PFMEA

Add the missed failure mode or strengthen the existing control.

WI and Control Plan

Update the method, frequency, limits, reaction plan, and ownership.

Poka-Yoke

Replace manual judgement with fixtures, sensors, interlocks, or automation.

NPI Governance

Convert the failure into a mandatory readiness or release gate.

Lesson Learned

Reuse the verified learning in the next relevant product or process.

“A corrective action becomes governance when the next project is protected before the defect returns.”

Portfolio-safe presentation: company names, customer names, project codes, employee names, product photographs, and confidential criteria have been generalized or removed.

Explore the connected engineering systems.

See how risk is identified through PFMEA and translated into built-in prevention through Poka-Yoke.

© 2026 Andreas Lelu Bastian · CAP Governance · Manufacturing Transformation & Operational Excellence