Every quality engineer walks into a launch with a head full of prior knowledge, whether or not they formalise it. You know the machine's history from the previous programme. You know that supplier's tendency to drift on bore diameter during tool wear. You know die-cast porosity clusters near the gate. None of that disappears when the first thirty parts arrive, and none of it should.
The classical approach treats each dataset as if it came from a virgin process. A hypothesis test on a new sample yields a p-value; if it clears the threshold, you act — discarding everything the launch team learned during development builds. That is wasteful. Bayesian thinking puts the prior knowledge on the table explicitly, then lets production evidence revise it.
The prior does not need to be a precise distribution computed on a whiteboard. It can be as crude as "the defect rate on this weld is somewhere between one in a thousand and one in ten thousand, based on the sister line at the old plant." A prior with that much uncertainty still carries real information: it fixes the order of magnitude, and the order of magnitude often determines whether you react at all.
Calibrating Prior Strength in Equivalent Observations
The trap is the opposite error: a prior so confident it swamps the data. If you were certain the process was fine, no amount of early scrap will move you. Across two decades of launches in automotive and aerospace, I have watched confident teams explain away three weeks of contrary evidence because their belief was never expressed in a form that could be updated.
The discipline of Bayesian thinking is calibrating how strong your belief actually is, in units of equivalent observations. The prior sample size represents exactly that: a beta prior with parameters equivalent to fifty inspected parts will resist a handful of rejects; one equivalent to five parts will not. Being honest about that number is half the work.
Calibration also has an organisational dimension. A prior stated in writing before launch can be challenged, discounted when tooling is reworked, and audited afterwards. A prior that lives in someone's head cannot. Write down the prior, its effective sample size, and who vouched for it — that is the minimum documentation for any belief you intend to update with production data.
The Machinery: Priors, Likelihoods and Sequential Updating
Formally, Bayesian updating is one line: the posterior belief is proportional to the prior belief multiplied by the likelihood of the data just observed. The practical power comes from applying that line repeatedly, part after part, shift after shift. Each inspection result does not reset the clock — it sharpens the picture.
For attribute data — pass/fail on a leak test, visual defects on a machined surface — the natural machinery is the beta-binomial model. Encode the prior as a beta distribution with parameters a and b, where a represents banked conforming evidence and b non-conforming evidence from before launch. Each good part increments a; each reject increments b. The mean is a/(a+b), and the width tells you how much uncertainty remains.
Variable data works the same way with conjugate normal models: you track a posterior mean and variance for a torque-tension correlation or a plating thickness. The updating mathematics is well established and fits on one page. What matters to the practitioner is the interpretation — you carry a living estimate of the process, and every measurement nudges it.
Sequential updating of a launch characteristic
- 01State the priorBeta(a,b) from development builds, sister lines or physics; record its effective sample size
- 02Collect evidenceEach conforming part increments a, each reject increments b
- 03Compute the posteriorUpdated distribution of the defect rate after every batch
- 04Apply the decision ruleQuarantine if P(defect rate exceeds escape threshold) rises above a stated level
- 05Review and challengePosterior versus prior inspected in a weekly forum; divergence is discussed, not hidden
Where Defensible Priors Come From
Honest sources of priors are more plentiful than people assume. Pre-production runs, even short ones, give you something. Capability studies on the development machine give you more. Tool wear curves from the tooling supplier's trials on similar geometries give you a drift model before the first chip flies. Each source carries a different effective sample size, and the discipline is representing that honestly.
Sister processes are the richest source in multi-plant operations. If three plants already run the same cold-heading operation and report consistent fraction-nonconforming behaviour, the fourth plant has every right to start from that belief and update with its own early production. I have seen launch teams argue for weeks about an alert threshold that a competent prior would have settled on day one.
Physics and failure-mode reasoning supply priors where data is thin. If crack initiation in a heat-treated shaft depends on quench delay, and you have measured the quench delay distribution, you can reason forward to a plausible defect-rate range before a single shaft has been run to failure. The prior will be wide — but wide is not empty, and it beats the implicit fifty-fifty prior that pretending ignorance actually imposes.
The key test for any prior is provenance. Write down where it came from, who vouched for it, and what would make it stale. If the tooling was reworked between development and launch, the development-build prior deserves discounting — represented in the maths as a smaller effective sample size. Priors are engineering judgements, and engineering judgements get documented.
Small Samples, Big Decisions
Bayesian methods earn their keep in the small-sample regime, which in quality means launches, engineering changes, low-volume aerospace work and rare failure modes. When you expect perhaps one defect in tens of thousands of parts, waiting for classical significance means waiting for a disaster to accumulate. The decision has to be made before the data is conclusive either way.
Consider escape-risk judgement on a containment. You have imposed a hundred-percent check and found nothing in the first few thousand units. The frequentist statement is thin: zero defects observed, so the upper bound on the defect rate is dominated by sample size alone. The Bayesian statement is richer: combine the zero with your prior on how bad the escaped material could plausibly be, and you get a posterior you can compare against the customer's tolerance.
Different priors give different posteriors — and making that sensitivity visible is a feature, not a bug, because it forces the argument about assumptions into the open. The same logic applies to acceptance sampling: under a beta-binomial model you can state the posterior probability that a lot exceeds the unacceptable quality level, and accept or reject against that probability rather than against a fixed plan whose risks were calibrated for someone else's process.
Rare-event monitoring is the clearest case. Suppose a cracking mode appeared at a known rate on the previous component generation, and the redesign aimed squarely at eliminating it. Early production shows zero cracks in a modest sample. Is the redesign working, or have you not looked hard enough? The posterior probability that the rate is genuinely reduced — old rate as prior, clean sample as likelihood — answers that question in a way no single confidence interval can.
A posterior built on a biased prior and contaminated evidence is not cautious statistics; it is confident nonsense with a decimal place.
Threats to Honest Inference
Bayesian machinery is honest only if its inputs are, and priors carry the biases of whoever sets them. The optimism bias of a launch team is documented in every industry: the engineers who designed the fix believe the fix works. If that belief goes in as a tight prior, early contrary evidence gets explained away — "that was a setup issue", "that unit was mishandled" — and the updating never bites.
My rule is structural: the person who owns the prior is not the person who owns the data. Have process engineering state the prior in writing before launch, and have the inspection function report the evidence without seeing what the prior predicts. Review the posterior against both in a forum where disagreement is expected. It sounds bureaucratic; in practice it takes twenty minutes a week during launch and catches divergence early.
Evidence contamination is the second threat. Censored inspection, non-random sampling from the top of the tote, operators rechecking marginal parts before logging them — all corrupt the likelihood term in ways no statistical model can repair. Before trusting a posterior, audit how the data was actually generated. Three questions suffice: what was the sampling frame, what happened to borderline results, and who had discretion to exclude anything.
Two failure modes of Bayesian practice
Prior dominates
- Tight prior set by the team that designed the fix
- Contrary evidence explained away as setup issues
- Updating never bites; scrap normalised
- Defence: separate prior owner from data owner
Data corrupts
- Non-random sampling from convenient locations
- Borderline parts rechecked or excluded before logging
- Likelihood term no longer reflects the process
- Defence: audit sampling frame and exclusion discretion
Where This Fits the Existing Toolkit
None of this replaces your existing instruments — it sits beneath them and explains when to trust them. A control chart is, roughly, a device for detecting when the stable-process prior has broken; Bayesian filtering makes that logic explicit and lets you tune it. A reliability demonstration test is a special case with a flat prior; choosing an informative prior changes the required test length dramatically, which is exactly the lever you want in aerospace programmes where test units cost as much as sold parts.
For launch management, the most useful artefact is a simple posterior tracker: one page per key characteristic, showing the prior, the cumulative evidence and the current posterior estimate with its uncertainty. Reviewed daily during ramp-up, it converts emotional arguments — "I think it's fine", "I don't trust this supplier" — into a shared, revisable picture.
When someone disagrees with the tracker, you can ask the productive question: what evidence would change your mind, and by how much? That question is the practical test of whether a disagreement is about data or about priors, and it can only be asked when both are written down. The cultural shift is the real deliverable: engineers who update beliefs in proportion to evidence — no more, no less — make faster decisions that are also defensible, because the reasoning trail from prior to posterior is open to challenge.
That trail is worth more than any single statistical output. Frequentist habit trains people to wait for enough data; production reality rarely grants that patience. Installing the updating habit before the first part is cut is the highest-leverage thing a quality leader can do at a launch.