Special characteristics: critical vs significant, and how they flow
Guide · Concepts · 7 min read
What special characteristics are, the difference between critical and significant, and why they must propagate from design through the PFMEA into the control plan.
Special characteristics are the thread that ties an APQP package together. Get them right and the PFMEA, control plan and PPAP reinforce each other. Get them wrong — or let one slip through a gap — and it's the first thing a customer's quality engineer or an IATF auditor will find.
What a special characteristic is
A special characteristic is a product or process feature that needs extra attention because variation in it has an outsized effect on safety, regulatory compliance, fit, form or function. Most dimensions on a drawing are ordinary — you make them to tolerance and inspect normally. A special characteristic is the handful that, if they drift, cause a real problem: a sealing surface, a bore position that drives assembly alignment, a weld that carries load.
Critical vs significant
Special characteristics are usually split into two classes, although exact names and symbols vary by customer:
- Critical characteristics affect safety or regulatory compliance. These map to the highest severities in your PFMEA (typically Severity 9–10) and demand the strongest controls — often error-proofing and 100% verification.
- Significant characteristics affect fit, function or customer satisfaction but not safety. They still need defined controls and capability monitoring, just not the safety-grade treatment.
Customers frequently use their own symbols and terms — "critical", "key", "fit/function", an inverted delta, a diamond, and so on. Those customer-specific definitions are themselves a PPAP element (number 17), so part of the job is mapping the customer's classes onto your own.
Where they come from
Special characteristics usually originate in design — flagged on the drawing or in the Design FMEA — and may also be dictated directly by the customer. Some emerge from the process side during the PFMEA, when the team realises a particular step's variation is what actually threatens a function. Either way, once a characteristic is designated special, it acquires obligations.
The propagation rule
This is the heart of it. A special characteristic must flow through the whole chain:
- It is identified (design / DFMEA / customer).
- It appears in the PFMEA, linked to the process step and failure mode that put it at risk.
- It is controlled in the control plan — with a specification, a measurement method, a sample size and frequency, and a reaction plan.
If a characteristic is critical in design but never reaches the control plan, you have no defined way to catch it in production. If it's controlled but not in the PFMEA, you can't show why it's controlled. The chain only works whole.
The common failure: the orphaned SC
The most frequent finding in a special-characteristic review is the orphan: a characteristic that exists in one document but not the others. It happens innocently — a late engineering change adds a special characteristic to the drawing, the PFMEA gets updated, and the control plan doesn't. On paper everything looks busy; in reality there's a hole.
Spreadsheets make orphans almost inevitable, because the PFMEA and the control plan are separate files maintained by hand. The structural fix is to make the special characteristic a single shared object that both the PFMEA and the control plan reference — so "is this SC controlled everywhere it should be?" is a question the system can answer, not a manual cross-check. That's exactly what SolidLaunchpad's method check does: flag any special characteristic that hasn't propagated into both the PFMEA and the control plan, before your customer does.
Special characteristics also connect directly to risk scoring — they're the features driving your highest severities — so they're worth reading alongside Action Priority vs RPN.
See it live in SolidLaunchpad
Describe a part and get an AIAG-VDA PFMEA, control plan and the 18-element PPAP — connected, with the method checking itself.