17. Supplier Data, Critical Characteristics, and Producibility

Friday, 8:28 a.m., supplier package spread next to internal Cpk charts.

The supplier says the process is stable.

Incoming variation says otherwise.

No one can tell whether the gap is process drift, measurement mismatch, or requirement ambiguity.

Until the discrepancy owner resolves that gap, schedule claims are unsupported.

Supplier truth must be operationally comparable

"Supplier says it is fine" is not evidence.

You need comparable evidence across teams:

  • same characteristic definition,
  • same measurement method or cross-calibrated method,
  • same acceptance criteria,
  • same revision baseline.

Without comparability, disagreements are endless and closure is slow.

Critical characteristics: keep the list tight

When teams label too many characteristics as critical, control plans lose focus and detection degrades.

Define a focused critical-characteristics set based on:

  1. safety/regulatory impact,
  2. function/yield impact,
  3. downstream rework cost if missed.

For each characteristic, specify:

  • nominal/limits,
  • measurement method,
  • sampling plan,
  • owner on both sides (internal and supplier),
  • revision baseline (aligned with the current controlled spec revision).

Minimum supplier evidence package

Before major commit, require:

  • latest controlled spec alignment confirmation,
  • capability evidence on critical characteristics,
  • measurement system notes,
  • recent drift/anomaly history,
  • containment and corrective-action status for open issues.

Require only the evidence package needed to make and record the commit decision.

Capability discussions in plain language

Do not let reviews drift into slide-heavy statistics discussion that delays a release decision.

Ask practical questions:

  • Can this process repeatedly hit the required window?
  • Under what conditions does it fail?
  • How quickly do we detect and contain drift?
  • What is the agreed response when it drifts?

Keep derivations in backup; keep pass/fail decisions in front.

Escalation playbook for discrepancies

When supplier/internal data conflict:

  1. freeze to known-safe operating state if needed,
  2. align revision and method baselines,
  3. run short joint verification plan with owners/dates,
  4. decide containment vs release based on agreed criteria,
  5. update risk register and one-page status.

Delay usually comes from unclear ownership at step 3.

A program sourcing custom precision components got the same answer from every supplier when asking about process tolerance: the process held a stated tolerance regardless of feature size. Multiple suppliers, independently, the same number. It had the feel of an industry rule of thumb repeated often enough that most programs treat it as settled.

The claim did not follow basic manufacturing physics. Process tolerances on formed or machined features typically depend on feature size because the relative contribution of variation is larger at smaller scales. Rather than accept the blanket number, dimensional data was requested across a range of feature sizes and geometries — not just the program's nominal part.

The data showed a clear size dependence. On large features, the supplier achieved roughly half the stated blanket tolerance — they were underselling their capability. On small features, the actual achieved tolerance was roughly double the stated value — they were overselling it. The blanket number was approximately their average across the range, misleading in both directions and most misleading at the feature sizes that governed the design constraints.

  • Old process: blanket tolerance accepted at face value, applied uniformly across all feature sizes in the design.
  • Artifact changed: a tolerance specification written as a function of feature size, derived from the supplier's own measurement data.
  • Measured improvement: an optimized component geometry fit the available form-factor envelope, cleared assembly placement requirements, and was physically sized to also benefit peak operating temperature — three constraints that had appeared to be in conflict under the blanket specification, resolved simultaneously.
  • Cost of the gap: without the size-dependent specification, the design would have been either over-constrained on large features (producing a component unnecessarily large for its envelope) or under-constrained on small features (relying on a tolerance the supplier could not hold, found during qualification).

The supplier discrepancy pattern here is the downstream consequence of the thermal limit revision — the power-stage supplier built to the 85 °C derating assumption; after the requirement revised to 78 °C, the receiving inspection flagged the discrepancy. The discrepancy playbook is what surfaces it as a capability gap, not a supplier failure.

Acceptable implementations for the supplier capability data exchange include an APQP or PPAP packet structure when the customer-supplier relationship is formal enough to require it, a supplier-collaboration object under product-data control when revision-locked handoffs are mandatory, a controlled exchange folder with revision-stamped attachments and a named review log for smaller programs, or a shared Cpk dashboard with defined refresh cadence. The OS cares that the capability data (Cpk values, measurement methods, sample sizes, and control chart history) arrives with the same revision control as the design requirements — not that it arrives through any particular tool.

Producibility as a continuous signal

Producibility is not a one-time pre-launch checkbox.

Track it through:

  • first article findings,
  • supplier drift patterns,
  • field-return signals,
  • design change impacts.

Without ongoing tracking, supplier drift is not visible until integration — after tooling is committed and the design is locked.