17. Supplier Data, Critical Characteristics, and Producibility

"The supplier says the process is stable, so we're good." Friday morning, the supplier package spread next to our own incoming Cpk charts, and that sentence was the whole basis for the schedule.

The incoming variation said otherwise. Nobody could tell whether the gap was process drift, measurement mismatch, or requirement ambiguity — and "the supplier says it's fine" is not one of those answers.

Until someone owns that discrepancy and closes it, the schedule claim is 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).

A tight characteristics list answers what matters; the evidence package determines whether the supplier can deliver it before the program commits.

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.

Three questions surface producibility risk before the tooling is cut:

  • 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. The playbook's other function is framing: a discrepancy resolved through the five steps is a process gap with an owner — not a supplier failure with a consequence.

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. Writing the tolerance specification as a function of feature size — derived from the supplier's own measurement data — resolved three constraints that had appeared to be in conflict under the blanket specification simultaneously: the component fit the available form-factor envelope, cleared assembly placement requirements, and was physically sized to benefit peak operating temperature.

Acceptable implementations for the supplier capability data exchange include 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. What matters is that the capability data — Cpk values, measurement methods, sample sizes, and control chart history — arrives under the same revision control as the design requirements.

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.

Field test: pick one supplier on your current program. Can you name the three critical characteristics you are tracking from them, and point to a controlled record with their latest measured values? If no, the supplier data link is not yet decision-grade.

Installing the OS inside a single program creates an island — without a deliberate rollout sequence, it does not spread to an organization that already runs its own process.